Re: [Talk-de] YouTube Account "OpenStreetMap Deutschland"
Hallo Sören, magst Du vielleicht noch einen News-Artikel für www.fossgis.de schreiben? Am besten gleich als Markdown und als Pull Request auf https://github.com/fossgis/fossgis-webseite ? Kannst auch noch etwas warten bis https://videos.openstreetmap.de hübscher geworden ist -- wie ihr wollt. Jochen On Sun, Jun 07, 2020 at 11:41:02PM +0200, Sören Reinecke via Talk-de wrote: > Date: Sun, 07 Jun 2020 23:41:02 +0200 > From: Sören Reinecke via Talk-de > To: talk-de@openstreetmap.org > Cc: Sören Reinecke > Subject: Re: [Talk-de] YouTube Account "OpenStreetMap Deutschland" > > Hi, > > nun ist es soweit. Unser YouTube Account > https://www.youtube.com/channel/UCjCS5VzsMI2TreDsIxWoIEg ist heute mit > zwei Videos online gegangen. Für Menschen, die YouTube nicht mögen, > gibt es https://videos.openstreetmap.de (Das befindet sich zurzeit im > Aufbau und soll noch einen hübschen Anstrich bekommen, insofern sind > Designideen gefragt :)) > > Wir werden nun nach und nach das Angebot weiter ausbauen. Die > dazugehörige Wikiseite > https://wiki.openstreetmap.org/wiki/Germany/Videos_zu_OSM wird > ebenfalls aktualisiert. Zu Anfang werden wir noch etwas träge agieren, > weil wir noch keine Workflows haben. Aber wir arbeiten daran. > > Wir sind in Moment zwei bis drei die das machen. Einer ist wieder > ausgestiegen. Insofern freuen wir uns auch über OSMler, die ebenfalls > zum Projekt "Videos zu OSM" beitragen wollen. > > Längerfristig soll es auch das Ziel werden, Videos mit veraltetem > Inhalt rauszunehmen und neu zu machen. Hat den positiven Nebeneffekt, > dass man die Videos dabei qualitativ verbessern kann. > > Danke an FOSSGIS e.V. für die Betreuung des Accounts und für die > Bereitstellung der Resourcen. Ich werde mich auch drum kümmern, dass > ich für die Community besser erreichbar werde. So kann man mich bei > Fragen etc. zum Projekt kontaktieren. > > Gruß > > Sören Reinecke alias Valor Naram > > On Sat, 2020-03-21 at 18:44 +0100, Sören Reinecke via Talk-de wrote: > > Hey, > > > > wenn ich mir Youtube angucke, dann finde ich sehr viele > > englischsprachige Videos zu OpenStreetMap in selten guter Qualität > > (eher schlecht oder mittelmäßig). Diese sind aber nicht gebündelt > > sondern bunt durchgemischt (kein offizieller Account, vielmehr kleine > > "Kräuter"). Es gibt z.B. keine mir bekannte Playlist zu "OSM Basics". > > Youtube ist dabei eine Plattform, die von vielen Menschen genutzt > > wird > > um neue Dinge kennen zu lernen. Youtube kann also dazu beitragen, > > dass > > OpenStreetMap bekannter wird und Eintrittsbarrieren nicht mehr so > > groß > > scheinen. > > > > Was sagt ihr dazu? Wir brauchen nur ein Team von Content-Producern. > > > > Gruß > > > > ~ Sören Reinecke alias Valor Naram, > > > > > > Developer of the Babykarte - https://babykarte.github.io > > Participating in MapDiscover project - https://mapdiscover.org > > "Community Supporter" for Trufi Association - https://trufi- > > association.org > > > > Ein Gag zu Hamsterkäufen: https://klopapier.mapdiscover.org id="-x- > > evo-selection-end-marker"> > > ___ > > 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 -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Mon, May 20, 2019 at 10:23:07PM +0200, Florian Lohoff wrote: > On Mon, May 20, 2019 at 09:32:25PM +0200, Jochen Topf wrote: > > > besorgt - Problem ist das entgegen der Doku die durch > > > das ST_Simplify doch kleiner werden und schneiden können. Muss man > > > also im Buffer entsprechend vorsorgen. Ausserdem entstehende da durchaus > > > mal seltsame Multipolygone. > > > > Wenn Du alles innerhalb einer Grenze haben willst, kannste das auch mit > > "osmium extract --polygon" machen und die Grenze direkt aus OSM nehmen. > > Wenn Du dann noch die "smart"-Strategie benutzt, dann ist auch die > > Grenze selbst garantiert drin. Vereinfachte Grenzen machen das Ganze > > etwas schneller, aber nicht viel. Und dann musste Dich nicht mit Buffern > > oder so rumärgern. > > Ich habe halt hier für meinen ganzen Auswertungsramsch diverse sub PBFs > von Deutschland die ich derzeit mit osmupdate/osmconvert update > und neu beschneide. Dafür brauche ich halt polys. > > osmupdate/osmconvert ist da ein wenig eigenwillig was das ausschneiden > angeht. Daher ist mir dann OWL/Regierungsbezirk Detmold um die Ohren > geflogen. Ich würde ja einfach auch osmium umstellen in der pipeline > aber da fehlt mir das mit dem dem automatisch update eines pbfs d.h. > download der change files. Das geht mit https://docs.osmcode.org/pyosmium/latest/tools_get_changes.html bzw. https://docs.osmcode.org/pyosmium/latest/tools_uptodate.html > Ich will doch einfach nur ein geographisches .pbf auf dem aktuellen > stand halten. Und das "consumerdevice" um das zu machen ist > halt osmupdate mit dem -B poly und schon läuft das für doofe. "für doofe" würde ich ja nicht sagen. Man muss ja schon wissen, dass man dabei ggf. nicht komplette Daten erzeugt und damit irgendwie umgehen. Aber hast recht, Osmium kann das nicht so einfach (gerade weil ich den User nicht "in Sicherheit wiegen" will). Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Mon, May 20, 2019 at 08:36:18PM +0200, Florian Lohoff wrote: > On Fri, May 17, 2019 at 07:22:06PM +0200, wambac...@posteo.de wrote: > > Moin > > > Am Ende war es vieles - poly von download.geofabrik.de der an einer > > > winzigen stelle einen node schneidet einer boundary. > > > osmupdate/osmconvert mit dem poly schneiden dann da einen teil der > > > boundary weg. > > > > Die Poly-Files der Geofabrik sind fast alle händisch erstellt worden, > > daher einfach und relativ schnell. Wenn sich aber eine Grenze verändert > > haben sollte, kann das (nie wieder angefasste) Poly-File schon mal > > falsch sein. > > > > Mein Tip: / > > /- https://wambachers-osm.website/boundaries// > > > > - bpoly mit einem Buffer von 1-2 km wählen und dann sind die > > *tagesaktuell*. ;) > > Da geht nen buffer? Das habe ich wohl übersehen. Habe mir > jetzt bei > > http://polygons.openstreetmap.fr/get_poly.py?id=73347=0.02-0.001000-0.005000 > > besorgt - Problem ist das entgegen der Doku die durch > das ST_Simplify doch kleiner werden und schneiden können. Muss man > also im Buffer entsprechend vorsorgen. Ausserdem entstehende da durchaus > mal seltsame Multipolygone. Wenn Du alles innerhalb einer Grenze haben willst, kannste das auch mit "osmium extract --polygon" machen und die Grenze direkt aus OSM nehmen. Wenn Du dann noch die "smart"-Strategie benutzt, dann ist auch die Grenze selbst garantiert drin. Vereinfachte Grenzen machen das Ganze etwas schneller, aber nicht viel. Und dann musste Dich nicht mit Buffern oder so rumärgern. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Thu, May 16, 2019 at 10:38:17PM +0200, Martin Koppenhoefer wrote: > > On 16. May 2019, at 21:03, Florian Lohoff wrote: > > > > osmosis --read-pbf file=detmold-regbez-latest.osm.pbf --tf accept-ways > >boundary=administrative --used-node --write-xml output.osm > > > > Grenzen extrahiert - und das ist falsch. Es exportiert eben Wege > > ohne boundary=administrative nicht > > > und wenn Du die Relationen und deren Member evtl. rekursiv mitfilterst? Oder > nur die Relationen mit members? > > Nur die ways klappt natürlich in dem Fall nicht, aber da kann man dem Osmium > keinen Vorwurf machen. Osmium kannste eh keinen Vorwurf machen, wenn dann Osmosis :-) Florian: Warum nimmste nicht einfach Osmium, das ist auch noch einfacher: osmium tags-filter detmold-regbez-latest.osm.pbf a/boundary=administrative -o output.osm Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag zu Id-referenzierten Ways zufügen?
On Fri, Jan 11, 2019 at 05:30:51PM +0100, Holger Bruch wrote: > Mit welchem Werkzeug könnte ich für ca. 1000 über Id identifizierte Ways > einer pbf-Datei ein Tag hinzufügen? > > Ich dachte an Osmosis, dessen tag-transform allerdings noch kein > Matching per Id unterstützt. Da gibts viele Möglichkeiten. Z.B. ein kleines PyOsmium-Skript. Oder Du schreibst ein kleines Skript, was mit "osmium getid" die Ways rausfriemelt, als OPL speichert und darin den Tag ändert und alles wieder zusammensetzt. Ein bischen programmieren wirst Du aber schon müssen. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Illegale Feuerstelle
On Mon, Dec 03, 2018 at 11:12:37AM +0100, Martin Koppenhoefer wrote: > Am Mo., 3. Dez. 2018 um 11:09 Uhr schrieb Florian Lohoff : > > > Entfernen. Ich habe auch auf den Nordseeinseln Wege durch die Dünen > > entfernt. Das waren gemappte Trampelpfade wobei das Betreten der Dünen aber > > untersagt ist. Angenommen jemand benutzt sein Handy als Navi würden > > wir ihn da durch führen. Oder auf der Karte sieht das so aus > > als dürfe man da durch. Und access=no hilft da ja auch nur > > am Rande. > > nach der Logik müsste man alle Wege entfernen, die nicht allgemein > zugänglich sind. Die Existenz eines Trampelpfads beweist ja, dass es dort > einen Weg gibt und der auch benutzt wird. Ich würde da informal=yes und > access=no drauf pappen, und wenn das nicht hilft, dann funktioniert die > Anwendung nicht. Meines Erachtens stiehlst Du Dich damit nur aus der Verantwortung als Mapper. Du kannst noch so viele Tags irgendwo dranhängen, um mit immer mehr und mehr Detail zu unterscheiden, was etwas ist. Natürlich wohl wissend, dass keine Anwendung diese Details unterscheidet. Und wenn sie das tut, der User nicht unterscheiden kann zwischen den 17 verschiedenen Strichlierungen des Weges und was das für ihn bedeutet. Letzlich bleibt es immer eine subjektive Entscheidung. Und wenn ich eh eine subjektive Entscheidung treffe, dann kann ich auch gleich sagen: Okay, das ist ein Weg oder, okay, das ist kein Weg. Das schöne an OSM ist, dass Menschen sowas entscheiden und nicht Algorithmen. Und Menschen können viele Informationen in diese Entscheidung einfließen lassen. Dazu gehört, wie etwas aussieht, aber auch wie die Umgebung aussieht (wenn es in der Nähe einen offiziellen Weg gibt, dann mappe ich den inoffiziellen vielleicht eher nicht z.B.), wie die beobachtete Nutzung durch Leute vor Ort ist usw. Und ja, da macht man Dinge auch mal falsch. Aber das ist okay, weil andere Mapper nach mir kommen und Dinge korrigieren können. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Illegale Feuerstelle
On Mon, Dec 03, 2018 at 11:06:04AM +0100, sepp1...@posteo.de wrote: > Die Prüfung ob legal oder illegal ist doch nicht Aufgabe von OSM - mal vom Sehe ich auch so. Mit irgendwelchen Spezialtags, die keiner auswertet, helfen wir letztlich niemandem. Also wenn da eine "echte" Feuerstelle ist mit eingefasster Feuerstelle, Grillrost oder dergl., dann würde ich es mappen, egal ob das nun legal ist oder nicht (on the ground rule). Wenn der Besitzer des Grundstücks oder die Gemeinde oder Forstverwaltung das nicht will, dass da Feuer gemacht wird, dann sollen die das Ding entfernen. Wenn da einfach nur eine Stelle auf dem Boden ist, wo man sieht, dass jemand Feuer gemacht hat, aber es nicht nach was "offiziellem" aussieht, dann würde ich das eh nicht mappen, weil es kann ja nächstes Jahr schon wieder zugewachsen sein. Sowas ist keine Feuerstelle, nur ne Stelle, wo mal ein Feuer war. Und dazwischen gibts natürlich einen Bereich in dem der Mapper abwägen muss. Und das ist gut so. Wenn ich z.B. weiß, dass da seit Jahren im Sommer jeden Tag jemand grillt, dann trage ich das vielleicht trotzdem als Feuerstelle ein auch wenn ich mir über den legalen Status nicht sicher bin. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnkilometer.ch
On Fri, Apr 20, 2018 at 07:13:16PM +0200, dktue wrote: > ich möchte gerne in der Schweiz die Autobahn-Kilometer pflegen und habe > hierfür eine Seite mit Hilfe der Overpass-API erstellt [1] (lange > Ladedauer!). > > Gerne nehme ich hierfür Verbesserungsvorschläge oder auch Pull-Requests auf > GitHub an [2]. > > Verwundert bin ich über die errechnete Gesamtlänge des Autobahnnetzes, > welche laut OSM-Daten derzeit 3817 km beträgt (entspricht ungefähr 1909km > bei einfacher Zählung beider Fahrtrichtungen) laut offiziellen Daten jedoch > nur 1447 km [3]. Kann jemand diese Differenz von rund 500 km erklären? Ich hab das mal auf andere Weise nachvollzogen: Download der Schweiz von der Geofbarik, dann osmium tags-filter switzerland-latest.osm.pbf w/highway=motorway -o \ motorways.osm.pbf osmium_road_length motorways.osm.pbf (das ist ein Beispielprogramm was bei libosmium dabei ist) ergibt: Length: 3069.67 km Durch zwei geteilt sind das ca. 1535 km, was viel besser passt. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation zu Poly-File aus PBF
On Sat, Sep 02, 2017 at 12:44:22PM +0200, dktue wrote: > ich möchte gerne kleine Regionen aus einer automatisch aktualisierten > planet-PBF-Datei ausschneiden, aber vor dem schneiden gerne die zum > Schneiden verwendenten .poly-Dateien aktualisieren. > > Am besten wäre es, wenn ich hierzu anhand der Relation-ID diese aus der > planet-PBF-Datei direkt extrahieren könnte. Allerdings kenne ich hierfür nur > dieses Pearl-Script [1], welches nur mit XML-Dateien umgehen kann -- für > Planet ist es keine Option, mit XML zu arbeiten. > > Kennst jemand ein Werkzeug (oder eine Werkzeug-Kette), dass mir aus einer > lokalen planet-PBF-Datei anhand der Relation-ID ein Poly-File schreibt, mit > dem ich dann (mit Hilfe von osmconvert) die Regionen ausschneide? Du kannst das mit Osmium (http://osmcode.org/osmium-tool) machen. Erster Schritt ist mit etwas wie osmium getid planet.osm.pbf -r 1234 -o rel.osm.pbf die Relation rausholen, die als Grenze dienen soll. Dann den Extract machen: osmium extract planet.osm.org -p rel.osm.pbf -o ausschnitt.osm.pbf Eine Poly-Datei brauchste nimmer, osmium kann direkt die OSM-Datei mit der Relation verwenden. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ich verzeifle daran eine .osc-Datei zu filtern
On Fri, Aug 04, 2017 at 12:46:56PM +0200, Kevin Hemker wrote: > > Ja, aber das muss eine Datenbank sein, die komplett alle Daten enthält. > > In den .osc-Dateien sind nur geänderte Objekte drin, nicht ungeänderte > > Objekte, die mit den geänderten zusammenhängen, wie es bei Nodes in Ways > > oder Ways in Relationen der Fall ist. > > > Verstehe ich das also richtig: Wenn an einem Way nur Tags geändert wurden > ist im .osc nur der Way mit den Tags, sowie den ID-Referenzen auf die Knoten > enthalten - die zugehörigen Nodes als solche fehlen aber, weil unverändert. > Wurde aber das Element in seiner Lage verändert, so sind neben den > Referenzen auch diejenigen Nodes komplett enthalten, die verschoben wurden? Jopp, das ist richtig. > > Aber eine allgemeine Empfehlung: Das OSM-Datenmodell ist komplex und das > > mit den Änderungen richtig hinzubekommen ist schwierig. Wenn es irgend > > geht, dann würde ich lieber einmal am Tag oder einmal die Woche einen > > kompletten Neuimport durchlaufen lassen oder so. Das macht es viel > > einfacher. > > > > Jochen > > Nach Erstsicht der augmented diffs teile ich diese Einschätzung; das > auseinanderzufriemeln wäre von der Performance her wahrscheinlich auch nicht > produktiver. > Allerdings ist ein kompletter Neuimport schon ein ziemlicher Overhead, > zurzeit ist die Updateroutine beim Projekt in PHP umgesetzt. > Für einen häufigeren Neuimport müsste ich mich dann wohl in C|Java > einarbeiten. Normalerweise ist der Bottleneck bei einem Datenbankimport der Import selbst, also die Datenbank bzw. der damit einhergehende I/O. Da macht es wenig Unterschied welche Programmiersprache Du verwendest. Um welche Daten geht es denn hier? So wie ich das verstanden habe, sind es ja nur ein paar POIs, die Du importieren willst, das sollte nicht wirklich sehr aufwändig sein. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ich verzeifle daran eine .osc-Datei zu filtern
On Fri, Aug 04, 2017 at 10:54:49AM +0200, Kevin Hemker wrote: > Allerdings dachte ich, gerade die osmChange-Dateien sind geeignet > Datenbanken aktuell zu halten... Ja, aber das muss eine Datenbank sein, die komplett alle Daten enthält. In den .osc-Dateien sind nur geänderte Objekte drin, nicht ungeänderte Objekte, die mit den geänderten zusammenhängen, wie es bei Nodes in Ways oder Ways in Relationen der Fall ist. > Ziel ist, eine eigene MySQL-Datenbank (die Informationen über Poi vorhält) > zu aktualisieren. Ways (also typischerweise Gebäude) sind darin durch ihren > Mittelpunkt repräsentiert. Bisher habe ich dazu (testweise in kleineren > Gebieten) den csv-export von overpass genutzt (DB-Inhalte vorher gelöscht > und dann neu eingespielt), aber nun möchte ich das Gebiet ausweiten und die > DB entsprechend aktualisieren statt täglich komplett neu zu füllen. > > Um dabei nicht jeden einzelnen Änderungseintrag durch meine DB-Updateroutine > jagen zu müssen und dort zu prüfen, ob er überhaupt in die DB soll möchte > ich vorher schon filtern, was wesentlich performanter ist. Du kannst versuchen, auf die augmented diffs zurückzugreifen, die haben dann alle abhängigen Objekte in der alten und neuen Version drin. Aber eine allgemeine Empfehlung: Das OSM-Datenmodell ist komplex und das mit den Änderungen richtig hinzubekommen ist schwierig. Wenn es irgend geht, dann würde ich lieber einmal am Tag oder einmal die Woche einen kompletten Neuimport durchlaufen lassen oder so. Das macht es viel einfacher. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ich verzeifle daran eine .osc-Datei zu filtern
On Thu, Aug 03, 2017 at 10:40:05PM +0200, Kevin Hemker wrote: > eigentlich ja keine große Sache, aber nach etlichen Stunden Verzweiflung > wende ich mich an euch und hoffe auf Hilfe: > > Ausgangspunkt: .osc-Datei vom osm-Server. Das Filtern soll folgendes > Ergebnis liefern: > > * keine Relationen mehr > * alle ways zu nodes konvertiert > * nur nodes behalten, die ein paar bestimmte keys haben. Eine .osc-Datei enthält zu einem Way nicht unbedingt alle Nodes, die in diesem Way sind. Daher wirst Du mit diesem Ansatz immer Probleme haben. Was willst Du denn am Ende erreichen? Wenn das Ziel ist, rauszufinden, wo es überall Änderungen bestimmter Art gegeben hast, dann reichen die .osc-Dateien nicht als Datenquelle aus. Du kannst Dir mal http://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs anschauen, vielleicht hilft Dir das weiter. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Elbe-Labe-Meeting 2017
Hi! Letztes Jahr hatten wir unser erstes Elbe-Labe-Meeting, dass Mitglieder der deutschen und tschechischen OSM-Community in Dresden zusammengebracht hat. Wir hatten Presentationen über Themen von Wanderkarten bis Auto-Navigation und viele interessante Diskussionen. Dieses Jahr planen wir etwas ein bischen anderes: Wir treffen uns in der Sächsischen Schweiz, einem Naturschutzgebiet, dass berühmt ist für seine Felsformationen und die vielen Wanderrouten, für ein Wochenende mit Wanderungen, Mappingaktionen, mit Gesprächen und generell allem rund um OSM. Der Spaß soll natürlich auch nicht zu kurz kommen. Wir haben ein Ferienhaus gemietet, das circa 20 Personen Platz bietet, Internet, Grill, und was man sonst noch so braucht, gibt es auch. Wikimedia Deutschland sponsort das Treffen, sodass es für die Teilnehmer kostenlos ist. Das Treffen findet vom 1. bis 3. September 2017 statt. Alle Details gibt es unter https://wiki.openstreetmap.org/wiki/Elbe-Labe-Meeting_2017 Wir laden alle OSMer ein, dabei zu sein. Da der Platz begrenzt ist, ist eine Vorregistrierung erforderlich. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osmconvert und nested relations
On Fri, Jun 16, 2017 at 11:04:27AM +0200, Christoph Hormann wrote: > On Friday 16 June 2017, Jochen Topf wrote: > > > > Es gibt da eine Tendenz immer komplexere Dinge zu mappen, ohne dass > > irgendwer diese Daten auch sinnvoll nutzt. Auf der einen Seite ist es > > ja gut, wenn wir mehr Details und mehr Zusammenhänge erfassen, weil > > nur Daten, die da sind, auch genutzt werden können. Aber auf der > > anderen Seite schreckt die Komplexität doch die Entwickler ab. > > In diesem Fall gibt es ein recht klares (wenn auch nicht immer einfach > bestimmbares) Kriterium: Wenn es für den Entwickler einfacher ist sich > den Zusammenhang aus den übrigen Daten herzuleiten, sollte man > gewöhnlich auf die Erfassung verzichten. In diesem Fall ist role > admin_centre von der Bedeutung äquivalent mit > capital=yes/capital= auf dem entsprechenden Element. Und > da der Entwickler letzteres aufgrund der Unvollständigkeit der > admin_centre eh auswerten wollen wird ist das Ganze am Ende meist > ziemlich überflüssig. > > Ansonsten ist das "denkt denn niemand an die armen Entwickler"-Argument > mit Vorsicht zu genießen, wenn die Bequemlichkeit der Entwickler über > die Bequemlichkeit der Mapper gestellt wird und dem Mapper sinnlose > Arbeiten aufgedrückt werden nur weil der Entwickler sich keine Arbeit > machen möchte oder seine Arbeit teurer ist als die des Mappers (was > insbesondere bei OSM ein sehr verbreitetes Problem ist). Es wäre ja schön, wenn wir die Arbeit der Mapper und der Entwickler irgendwie verrechnen könnten und schauen, was "unterm Strich" am effizientesten ist oder so. Das könnte man machen, wenn OSM eine Firma ist, die ihre Leute passend einteilen kann. Aber so ist das halt nicht. Das Problem ist ein anderes: Der Mapper denkt, sein komplexes Mapping würde auch magisch irgendwie verwendet. Es erscheint auf der Karte oder ist findbar im Nominatim oder wird beim Routing verwendet. Das ist aber häufig nicht der Fall. Wir sind meilenweit hinten dran mit der Entwicklung. Es gibt wahnsinnig viele Sachen, die theoretisch vielleicht möglich wären, die praktisch aber nicht funkionieren. Vielleicht gibts sogar Versuche hier oder dort, aber praktisch ist das, was wir von den OSM-Daten wirklich nutzen, ziemlich klein. Dadurch fehlt hier aber ein ganz wichtiges Korrektiv: Klassisch ist das so, dass der Mapper sich auf das stützen kann, was auf der Karte erscheint. Mapper mappen solche Sachen konsistent und qualitativ einigermaßen gut, wo sie das Ergebnis anschauen können. Ob das nun gut ist oder nicht, Mapper orientieren sich an der Karte (und auch an der Visualisierung der diversen Tools zur Qualitätssicherung). Aber da, wo es diese "guidance" durch solche Karten und Tools nicht gibt, gibt es einen unglaublichen Wildwuchs. Der Wildwuchs ist gut, wenn aktiv in dem Bereich etwas voran geht. So kann man nämlich verschiedene Dinge ausprobieren und dann das, was am besten funktioniert, systematischer umsetzen. Dazu braucht es aber irgendwen, der die Daten auch nutzt und sagt, was funktioniert und was nicht. Und das fehlt halt in vielen Bereichen. Beim public transport z.B. ist diese "Diskussion" noch voll im Gange, da bewegt sich was und neue Dinge werden probiert. Aber in ganze vielen anderen Bereichen, gerade was komplexe Relationen angeht, da passiert das nicht. Damit OSM als System funktioniert, das sich fortentwickelt und praktische Lösungen liefert, braucht es beides. Die Mapper, die Daten sammeln und erfassen und die Nutzer, die aus den Daten etwas machen. Aus dieser Zusammenarbeit entsteht eine nützliche Datensammlung. Fehlt das eine oder das andere, dann geht es nicht voran. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osmconvert und nested relations
On Fri, Jun 16, 2017 at 11:22:12AM +0200, dktue wrote: > vielen Dank für den Hinweis bezüglich der Relationen: In der Tat handelt es > sich beim der Grenze nicht um eine geschachtelte Relation sondern um eine > einfache Relation mit ausschließlich Ways als Mitgliedern. > > Ich habe folgenden Test gemacht: Ich habe die Daten der Regierungsbezirks > Tübingens heruntergeladen [1] und mit osmconvert und folgendem Parameter > geschnitten: > > osmconvert.exe tuebingen-regbez-latest.osm.pbf > -b=9.07966,48.50007,9.08387,48.50192 --complex-ways -o=test.osm > > Ich hätte erwartet, dass in der Ausgabe-Datei die vollständigen Grenzen von > Tübingen und Kusterdingen enthalten sind. Das ist aber leider nicht der > Fall. Ich weiss nicht genau, wie osmconvert das handhabt. Bei osmium kann man einstellen, welche Relationen man vervollständigt haben möchte. Siehe http://docs.osmcode.org/osmium/latest/osmium-extract.html . Normalerweise werden nur multipolygon-Relationen vervollständigt, aber man kann auch sagen, dass das auch für die Grenzen gelten soll. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osmconvert und nested relations
On Fri, Jun 16, 2017 at 10:02:58AM +0200, Martin Koppenhoefer wrote: > > On 14. Jun 2017, at 19:07, Michael Reichert <osm...@michreichert.de> wrote: > > > > Grenzenrelationen referenzieren keine anderen Relationen. Die einzigen > > anerkannten Mitglieder sind > > - Ways mit der Rolle outer > > - Ways mit der Rolle inner > > - Ways ohne Rolle (der Auswerter darf dann raten) > > - 1 Node mit der Rolle admin_centre > > - 1 Node mit der Rolle label > > > > gibt es einen Grund, als admin_centre nur nodes zuzulassen? Wieso keine place > polygone? Die Frage wäre hier erstmal: Wer macht eigentlich was mit diesen Daten? Es gibt da eine Tendenz immer komplexere Dinge zu mappen, ohne dass irgendwer diese Daten auch sinnvoll nutzt. Auf der einen Seite ist es ja gut, wenn wir mehr Details und mehr Zusammenhänge erfassen, weil nur Daten, die da sind, auch genutzt werden können. Aber auf der anderen Seite schreckt die Komplexität doch die Entwickler ab. Nun macht es das Leben eines Entwicklers nicht wirklich schwieriger, ob es 10 verschiedene Typen von Shops gibt oder 100 oder 1000. Aber komplexe Relationen auswerten, das ist schwierig und kann selbst bei kleinen Änderungen erhebliche Auswirkungen haben. Da muss man schon viel genauer hinsehen, was sinnvoll ist und was nicht. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie viel Werbung sollte in die Wochennotiz?
On Thu, Jun 30, 2016 at 12:23:10AM +0200, Christoph Hormann wrote: > On Wednesday 29 June 2016, Michael Reichert wrote: > > [...] > > > > Wir möchten von euch als Leser und OSM-Community wissen, welche > > Meinung ihr zu folgender Frage habt: > > > > Sollten wir Meldungen von Firmen, die sich gar nicht oder nur in sehr > > geringem Maße in der OSM- und/oder Open-Source-Community engagieren, > > im Zweifelsfall weglassen? (Auch weiterhin wird es Fälle geben, in > > denen die Meldung auf jeden Fall relevant ist und von uns > > veröffentlicht werden wird) > > Meine Meinung ist, dass das generelle Engagement der Firma für OSM/OS > hier bedeutungslos sein sollte. Entscheidend sollte ausschließlich > sein, ob die Nachricht von Interesse für die Leserschaft ist. Das > bedeutet nicht, dass alles, was auch nur für einen einzigen Leser von > marginalem Interesse ist rein sollte - entscheidend ist das > durchschnittliche Zielpublikum - welches natürlich durchaus einen > Interessenschwerpunkt Richtung OSM/OS hat. Und es spricht auch nichts > dagegen so was wie einen Bildungsauftrag zu sehen. > [...] Dem stimme ich voll zu. Es geht immer darum, was ihr denkt, was Eure Leser lesen wollen. Dann ist das auch keine Werbung, sondern eine Nachricht. Auf keinen Fall sollte der Inhalt der Wochennotiz an irgendetwas anderes gebunden sein, als Eure Meinung, was interessant ist. Darum lesen "wir" die Wochennotiz, weil wir darauf vertrauen, dass ihr das richtige auswählt. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wann geht eine Bahnstrecke in Betrieb?
On Do, Mai 05, 2016 at 11:36:06 +0200, Michael Reichert wrote: > Sollte man die Bahnstrecke in railway=rail umtaggen, wenn sie für die > allgemeine Nutzung offen ist (d.h. jedes Eisenbahnverkehrsunternehmen > dort fahren darf, sofern die Fahrzeuge für die Strecke geeignet sind)? > Oder soll man schon umtaggen, wenn die Testfahrten beginnen? Ich gehe hier mal vom Otto-Normal-Mapper aus, der keine speziellen Fachkenntnisse hat. Der guckt sich an, wie etwas aussieht und mappt das dann. Das ist unser Massstab bei OSM. Der sieht eine Bahnstrecke, die fertig aussieht und auf der gelegentlich Züge hin- und herfahren. Dann macht es keinen Sinn, das als construction zu taggen. Das ist ne Bahnstrecke. Ob die Strecke laut Bundeseisenbahnbaundbetriebsgesetz Paragraph 08/15 offiziell in Betrieb ist oder nicht, das ist eine Frage, die für OSM erstmal keine Rolle spielt. Bei einer noch nicht eröffneten Strasse ist durch einen Laien ohne weiteres ersichtlich, dass sie nicht offen ist, weil sie durch entsprechende Schilder und Absperrungen so gekennzeichnet ist. Bei einer Bahnstrecke ist das nicht unbedingt der Fall. Und auch wenn ich mir anschaue, wie das vom Benutzer der OSM-Daten aussieht, komme ich zu dem gleichen Schluss: Wenn ich mich im Gelände orientiere und sehe eine hübsche neue Bahnstrecke, die in der Karte gestrichelt gemalt wird, dann sieht es für mich aus, als ob die Karte veraltet ist, oder ob ich vielleicht an der falschen Stelle bin. Liegt da überall Baumaterial rum, dann erwarte ich was anderes. Routen kann man auf Bahnstrecken eh nicht in der selben Form, wie man das auf Strassen kann. Nur weil eine Strecke offiziell freigegeben ist, heisst das ja nicht, dass da auch Züge fahren. Also ganz klare Antwort: Umtaggen, wenn es für den Laien so aussieht, als ob die Strecke fertig ist. Das ist einfach nur eine weitere Form der "on the ground rule". Spezialinteressen haben bei OSM gegenüber dem, was allgemein nützlich und erwartet wird, zurückzutreten. Meiner Ansicht nach gehört die Information, welche Strecken offiziell freigegeben sind, überhaupt nicht nach OSM, weil es eine Spezialinformation ist, die sich "on the ground" nicht verifizieren läßt. Aber ich werde mich jetzt auch nicht beschweren, wenn die Eisenbahnmapper dafür einen besonderen Tag erfinden. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Geodaten in Sachsen - Bitte noch abwarten
On Sa, Feb 13, 2016 at 09:21:46 +0100, Joachim Kast wrote: > Diese Antwort erinnert mich sehr an Baden-Württemberg, wo die > veröffentllichten Daten [3] zwar unter inkompatiblem CC-BY stehen, aber > der Minister per Presseerklärung [4] die OSM-Nutzung gestattete. > [4] > https://mlr.baden-wuerttemberg.de/de/unser-service/presse-und-oeffentlichkeitsarbeit/pressemitteilung/pid/amtliche-geodaten-werden-kostenlos-zur-verfuegung-gestellt-1/ Mir ist unklar, wie Du aus dieser Presseerklärung eine Erlaubnis für die OSM-Nutzung rausliest. Da steht nur die Behauptung "Damit sei auch eine langjährige Forderung der OpenStreetMap-Community erfüllt." Das kann ich so nicht nachvollziehen. Was genau war denn diese Forderung? Sicher ist es besser, dass die Daten so rausgegeben werden, als dass es sie nur gegen Geld gibt. Das freut uns natürlich. Aber nutzbar sind sie so für uns immernoch nicht. Und selbst wenn in der Presseerklärung mehr drin stände, eine Presseerklärung ersetzt keine klare juristische Aussage der zuständigen Landesämter. Ich kann die Datenlizenz Deutschland – Namensnennung – Version 2.0 nur so lesen: Wenn man die Daten irgendwie nutzt, dann muss man die Quelle (LGL bzw. halt das Land Sachsen) erwähnen. Diese Forderung "vererbt" sich bis zum Endnutzer der Daten. Wenn die Daten aber mit unseren vermischt werden in OSM, dann fordern wir hinterher nur noch, dass OSM genannt wird. Und damit ist das ganze inkompatibel. Für mich ist also weiterhin klar: Wir dürfen diese Daten nicht in OSM importieren. Da hilft kein rumreden. Entweder die Ämter ändern die Lizenz komplett oder sie geben uns eine klar formulierte Sonderlizenz. Wir haben dieses Thema doch schon tausendmal gehabt mit anderen Datenquellen. Wir brauchen eine juristisch einwandfreie Aussage, dass sie damit zufrieden sind auf http://www.openstreetmap.org/copyright in der Liste der Contributors genannt zu werden und dass sich darin dann ihr Recht auf Namensnennung erschöpft. Wenn Sie das unterschreiben, dann ist das okay, vorher nicht. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Download von .osm Daten
http://download.bbbike.org/osm/ On Mo, Okt 19, 2015 at 09:34:12 +0200, Heinz-Jürgen Oertel wrote: > Date: Mon, 19 Oct 2015 21:34:12 +0200 > From: Heinz-Jürgen Oertel <hj.oer...@t-online.de> > To: talk-de@openstreetmap.org > Subject: [Talk-de] Download von .osm Daten > > Hallo, > > Ich möchte mit mapweaver eine Karte als SVG erzeugen > und benötige dafür Eingangsdaten. Der Bereich umfasst > Teile der Ukraine, > Teile von Moldavien, > Teile von Rumänien, und > Teile von Bulgarien > > Mit welchem Tool kann ich diese Downloaden? > Z.B. unter Angabe einer Bounding Box. > > Aus dem planet.osm mit osmosis zu extrahieren > erscheint mir zu aufwändig, di ich dann zunächst > das riesige planet.osm downloaden müsste. > > Oder kann man die existierenden land.osm > erst zusammenfügen und dann den Bereich mit osmosis extrahieren? > > Für Eure Hilfe herzlichen Dank. > > Heinz > > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Taginfo update
Hi! Taginfo hat die Woche ein Update bekommen. Zusammen mit Christopher Baines habe ich an der Mobil-Fähigkeit der Webseite gearbeitet. Einige Bugs wurden gefixt und einige Abfragen, die sehr langsam waren, sind jetzt sehr schnell. Aber die größten Neuigkeiten betreffen das neue Taglist-Feature: Taginfo kann jetzt automatisch die Tag-Tabellen erzeugen, die man überall im Wiki sieht. Unter http://wiki.openstreetmap.org/wiki/Taginfo/Taglists gibts dazu Erklärungen. Dies sollte sehr nützlich sein, die manuelle Arbeit im Wiki zu reduzieren. Ausprobieren wie immer unter: https://taginfo.openstreetmap.org/ Mehr Details in meinem Blog unter http://blog.jochentopf.com/2015-08-15-hacking-on-taginfo.html Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Moeglicher Mapnik- oder Tagging-Bug: Blaues Land
On Sun, Jul 19, 2015 at 01:41:31PM +0200, markus schnalke wrote: [...] Der Fehler tritt nur auf manchen Zoomstufen und nur bei maenchen Tiles der Insel auf. OSMI zeigt bei der Coastline-Pruefung keine Fehler an. Sonst wusste ich nicht, was ich noch haette pruefen sollen. Es kann durchaus mal sein, dass Du die Küstenlinien schon wieder repariert ist und Du daher im OSMI keinen Fehler siehst, aber die Tiles noch nicht alle neu gerendert sind (oder in der Zeit, wo der Fehler in den Daten war, nicht neu gerendert wurden) und daher manche eben den Fehler anzeigen und andere nicht. Genauer gesagt ist das sogar das typische Verhalten. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mangelhafte Namensnennung auf Mapbox-Karten
On Fri, Jul 17, 2015 at 10:07:05AM +0200, Frederik Ramm wrote: [...] Einfluss etc. etc., und dann wird es im Einzelfall gefixt und zwei Tage später taucht der nächste Mapbox-Kunde mit einer unzureichenden Namensnennung auf. [...] Ist das zwei Tage später anekdotisch oder irgendwie belegt? Was mir bei dieser Diskussion immer fehlt ist eine klarere Vorstellung davon, wie groß das Poblem wirklich ist. Wieviele Mapbox-basierte Karte haben eine Attribution und wieviele haben das nicht? Haben wir eine Liste der Fälle, wo die Attribution nicht in Ordnung war, wann wurde das gemeldet, wann wurde es korrigiert? Man kommt bei sowas sehr leicht in einen confirmation bias rein, weil man halt, einmal darauf aufmerksam gemacht, die Probleme sieht und nicht mehr die Fälle, wo es keine Probleme gibt. Und dann macht man ein Problem größer, als es in Wirklichkeit ist. Wenn wir wirklich ein systemisches Problem nachweisen können, dann sollte man das gemeinsam mit Mapbox lösen. Aber etwas mehr als zwei Tage später taucht der nächste [...] auf, sollte es halt schon sein. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fußgänger-Diskriminierung?
On Fr, Apr 17, 2015 at 09:17:45 +0200, Frederik Ramm wrote: Ich bin nach wie vor der Ansicht, dass Du hier eine Arbeit, die Du als Router nicht tun willst, dem Renderer zuschiebst. Die Regel Namen an Fusswegen nur rendern, wenn der gleiche Name nicht bereits in unmittelbarer Nähe für eine parallel laufende Strasse verwendet wird, die für ein gutes Kartenbild dann notwendig wäre, kann ich mit bestehender Technologie nicht ohne weiteres performant umsetzen. Ich denke das ist ein ganz wichtiger Punkt hier. Der Ansatz von Roland, die Namen überall einzutragen mag zwar logisch erscheinen. Aber wir haben halt nunmal sehr viel Renderer (bzw. Kartenstile), die damit nicht umgehen könnten. Und ich sehe auch nicht, wie man das mit vertretbarem Aufwand in die Software einbauen kann. Wir würden damit also bestehende Anwendungen vor ein Problem stellen. Routersoftware auf der anderen Seite gibt es nicht so viel und sie muss eh eine deutlich aufwändigere Vorverarbeitung durchführen. Es macht also mehr Sinn, ihr die Extra-Arbeit aufzubürden, ggf. parallele Wege zu finden und damit etwas schlaues zu machen. Klar ist außerdem, dass es eine perfekte Lösung nicht geben wird. Wir alle wollen keine Relationen an jeder einzelnen Straße, die sie mit parallelen Fußwegen verbindet oder so. Aber vielleicht gibt es ja eine andere Lösung, die praktikabler ist. Ich glaube schon, dass es sich lohnt darüber nachzudenken. Mal einfach so ins Blaue phantasiert: Man könnte auf parallel verlaufendenn Fuss- und Radwegen, Wirtschaftswegen, Anliegerfahrbahnen usw. ein zusätzliches Tag anbringen, das aussagt: Dies ist ein Nebenweg der mehr oder weniger parallel zu einem Hauptweg lang geht. Dieses Tag könnte beim Rendering bzw. bei der Suche herangezogen werden, um den Straßennamen zu unterdrücken. Der Name kann dann auf die Nebenwege drauf, der Router kann ihn wie von Roland gewünscht nutzen. So ein Tag hätte auch den Effekt, dass es für Algorithmen, die parallele Wege finden wollen als Hint benutzt werden kann. So ein Algorithmus muss dann nicht mehr aufwändig alle Ways checken, ob sie vielleicht zu irgendeinem anderen Way parallel sind, sondern nur noch die, die dieses Tag haben. Das könnte eine erhebliche Vereinfachung sein. Zusätzlich gibt uns so ein Tag die Möglichkeit, automatische Checks zu machen. Z.B. kann man parallele Ways finden, die das Tag nicht haben, aber gleiche Namen. Oder umgekehrt: parallele Ways, die verschiedene Namen haben. Das ist zwar aufwändig, aber muss ja nur von Checkskripts a la OSM Inspector oder Osmose gemacht werden. Wenn man sowas in die Richtung einführen würde muss man aber doch noch alle Rendering Styles ändern, das wäre ein sehr großer Schritt. Alternativ könnte man natürlich auch einen neuen name-Tag einführen: Name des parallel führenden Hauptweges. Damit muss man beim Rendering nichts ändern. Die Frage ist dann nur, ob wir morgen noch einen Zusatztag für Refs brauchen und übermorgen für bridge usw. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Storchenhorste mappen
On Fr, Mär 27, 2015 at 05:35:38 +0100, Alexander Lehner wrote: On Fri, 27 Mar 2015, dezent...@web.de wrote: Der Frühling kommt und mit ihm die Störche. Warum also nicht die gut auffindbaren Horste in die OSM mit aufnehmen? [...] Ohne jetzt einen post-war anzetteln zu wollen, der wahrscheinlich aber nicht ausbleibt: Auf der FOSSGIS vor 2 Wochen wurde dieses Thema auch schonmal diskutiert und laeuft letztlich auf eine ethische Frage hinaus. Es ist wunderbar, seltene Arten zu finden und beobachten zu koennen. Andererseits verleitet diese Information vielleicht dazu, eine Art 'Storchennest-Tourismus' zu etablieren. Bei geschuetzten oder gefaehrdeten Arten ist es oft so, dass die Neste/Brutplaetze/Futterplaetze explizit von einen Foerster oder wasauchimmer beschuetzt und geheim gehalten werden, um sie in Ruhe zu lassen. Diese Idee finde ich persoenlich nicht schlecht, es kann halt einfach nicht jeder zu einem Adlerhorst auf einer Leiter hochklettern um dort die Kueken anzusehen. Andererseits sind die 'normalen' Klapperstoerche ja auch Zivilisationsfolger und nisten gerne auf dem Kamin einer Baeckerei. Da saehe ich jetzt z.B. kein Problem das in OSM einzutragen. Wie immer eine Ermessensfrage der Community ;) Als wir das auf der FOSSGIS besprochen haben, waren eigentlich letztlich alle der Meinung, dass Storchennester kein Problem sind. Problematisch sind Nistplätze von seltenen Seeadlern und sowas. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] was:*= oder old_*= tag prefixing Was: Re: Taginfo-Challenge
On Sat, Mar 14, 2015 at 09:06:00PM +0100, Florian Lohoff wrote: On Fri, Mar 13, 2015 at 07:52:22AM +0100, Jochen Topf wrote: Hi! Eine Woche nach meiner Taginfo-Challange haben wir einen sichtbaren Knick in der Statistik, wie man hier sehen kann: http://taginfo.openstreetmap.org/reports/historic_development Aber es sieht so aus, als ob das Interesse schon nachläßt. Oder vielleicht ist es auch, weil alle diese Woche auf der FOSSGIS sind. Es gibt noch viel zu tun. Weiter so! Wer nicht weiß, wovon ich rede, kann das hier nachlesen: http://blog.jochentopf.com/2015-03-05-new-taginfo-features-and-a-challenge.html Ich habe mir ja jetzt mal den Spass gemacht und auch mal ein paar Sachen aufgeräumt und da stolpert man ja echt über Klamotten. Haufenweise wege auf denen alle tags in ein was:*=value umgewandelt wurden (alternativ auch old_*=value). Das sind zum überwiegenden Teil Wege die scheinbar Rückgebaut wurden. Manchmal finden sich auch noch FIXMEs/notes da drauf die bitte nicht von alten Luftbildern neu hinzuzufügen. Meiner Meinung nach reicht da ein nackiger way mit einem note drauf. Wie man auf die idee kommen kann anstatt die Versionierung der Datenbank die tags auf old_/was: status zu kopieren erschliesst sich mir nicht. Ich habe da low-frequency mal ein paar Sachen entfernt d.h. dort wo wege NUR was:* tags hatten habe ich den weg entfernt und da wo noch andere tags mit drauf waren habe nur das sammelsorium von was:* tags entfernt. Semantisch ändert sich da ja eh nichts. Wie halten das andere die hier mit aufräumen mit dererlei tags? Flo PS: Mit dem old_ gibts ja gängige nutzung so wie old_name= oder so aber ein old_highway=service old_service=driveway old_width=2 als alleine tags auf einem weg können dann auch weg. Zu allem: +1 Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taginfo-Challenge
On Sat, Mar 14, 2015 at 01:59:04PM +0100, Andreas Goss wrote: Da ich letztes mal noch keine Antwort bekommen hatte, wie sieht es mit case sensitive key aus? Spielt das für die Datenbank eine Rolle, also sollten alle key klein sein? Oder ist es egal, dann wäre es gut wenn Taginfo das da einfach ignoriert. Die Datenbank ist case sensitive also ist es taginfo auch. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taginfo-Challenge
On Sun, Mar 15, 2015 at 03:33:46PM +0100, Florian Lohoff wrote: Hast du mal darüber nachgedacht die defakto eingeführte Namespace Geschichten irgendwie mit abzudecken? turn:lanes destination:lanes etc - Defakto sind das ja 2 etablierte tags die jeweils einfach nur in einem namespace extended sind. Ich habe im moment keine super idee wie man das zerpflückt. Auf der anderen Seite findet man im moment turn:lanes und lanes:turn Ja, habe ich mal überlegt, aber ich weiss auch nicht so recht, wie das aussehen soll. So richtig einheitlich sind diese Namespaces oder Sub-Keys oder Prefixe, oder wie man das auch nennen will, nicht. Es gibt häufig den Ansatz, dass es zu Tag foo=* ein foo:bar=* gibt, dass das genauer beschreibt. Aber es gibt auch z.B. source=* und source:foo=*, wo das source:foo genauer beschreibt, wo der foo=* Tag herkommt. Hier wird also aus dem source und dem foo zusammen was neues. Und wie du ja schon schreibst, manchmal foo:bar, manchmal bar:foo (und manchmal auch foo_bar zusätzlich). Dann gibt es name:SPRACHE, aber auch name:botanical und so weiter. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Taginfo-Challenge
Hi! Eine Woche nach meiner Taginfo-Challange haben wir einen sichtbaren Knick in der Statistik, wie man hier sehen kann: http://taginfo.openstreetmap.org/reports/historic_development Aber es sieht so aus, als ob das Interesse schon nachläßt. Oder vielleicht ist es auch, weil alle diese Woche auf der FOSSGIS sind. Es gibt noch viel zu tun. Weiter so! Wer nicht weiß, wovon ich rede, kann das hier nachlesen: http://blog.jochentopf.com/2015-03-05-new-taginfo-features-and-a-challenge.html Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neue taginfo-Features und eine Herausforderug
Hi! Taginfo hat gerade ein neues Feature bekommen, es kann jetzt ähnliche Keys finden. Nützlich ist das um verwandte Keys zu finden, aber auch um jede Menge Vertipper zu finden und zu korrigieren. Und ich hoffe die Community wird letzteres kräftig tun... Mehr dazu unter http://blog.jochentopf.com/2015-03-05-new-taginfo-features-and-a-challenge.html Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue taginfo-Features und eine Herausforderug
On Fr, Mär 06, 2015 at 08:03:52 +0100, Frederik Ramm wrote: On 03/05/2015 05:26 PM, Jochen Topf wrote: Taginfo hat gerade ein neues Feature bekommen, es kann jetzt ähnliche Keys finden. Nützlich ist das um verwandte Keys zu finden, aber auch um jede Menge Vertipper zu finden und zu korrigieren. Und ich hoffe die Community wird letzteres kräftig tun... Ich möchte Jochens im Blog geäusserte Bitte um Sorgfalt unterstreichen. Keine 24 Stunden ist der Blog-Eintrag alt, und wir beobachten schon das zu erwartende ich meinte es doch nur gut-Chaos bei mechanischen Edits. Zwei Beispiele: * Ein User ersetzt großflächig bulding=... mit building= Weil er sich die einzelnen Objekte dabei nicht anschaut, merkt er nicht, dass auch eine ganze Reihe bulding=bulding-Objekte dabei sind, die er jetzt in das wenig sinnvolle building=bulding geändert hat. * Ein User ersetzt großflächig Building=... mit building= Weil er sich die einzelnen Objekte dabei nicht anschaut, merkt er nicht, dass auch eine ganze Reihe von Nodes, die Teil eines building=yes-Ways sind, mit Building=yes getaggt waren - ein Tag, das man entfernen hätte müssen statt es umzubenennen. Solche Edits verschlechtern die Datenlage auf zwei Arten. Einmal können bislang schlafende unsinnige Daten damit aufgeweckt werden wie im zweiten Beispiel. Ausserdem werden unsinnige Edits umso glaubwürdiger, je mehr Leute sie angefasst haben. Wenn man unsere Daten jetzt oberflächlich anschaut, wird man feststellen: Oh, dieses building=bulding ist ja gerade erst vor einigen Tagen aktualisiert worden, und das noch von einem erfahrenen Mapper - irgendwas muss also dran sein an dem building=bulding... - sowas kann in einem Einzelfall passieren, oder auch in einer statistischen Auswertung (34 verschiedene Mapper haben Objekte vom Typ building=bulding editiert, na dann kann es ja so falsch nicht sein). Also, langer Rede kurzer Sinn: Augen auf beim Typos fixen, und nicht mit dem Rasenmäher drüberhoppeln bitte. Ich hätte das klarer ausdrücken sollen in meinen Postings. Danke, Fred, ich kann das nur alles unterstreichen, was Du sagst und will noch einen weiteren Grund drauflegen, warum solche Massenedits ohne Betrachtung jedes einzelnen Objektes schlecht sind: Die Typos sind ein einfach zu findender Hinweis, dass mit den Objekten was nicht stimmt. Es ist häufig so, dass wenn eine Sache nicht stimmt, es auch andere Probleme mit einem Objekt gibt. Fixt man die jetzt nicht alle, sondern nur den offensichtlichen Fehler, dann hat man damit die anderen Fehler quasi verdeckt. Es wird schwieriger die in Zukunft zu finden. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TagFinder - eine Volltext-Suchmaschine für OSM Tags (Prototyp)
On Mo, Jan 19, 2015 at 04:31:48 +0100, Michael Kugelmann wrote: Am 18.01.2015 um 23:52 schrieb Stefan Keller: Am 18. Januar 2015 um 23:17 schrieb Joachim Kast osm...@dd1gj.de: Für die Thumbnail-Darstellung wird ein Bild von 1.704px × 2.272px und einer Größe von 1,8 MB heruntergeladen. Schmalband-Anbindungen machen da schlapp. Hmm, stimmt. Ist aber etwas schwierig für den Empfänger, das vorauszusehen :-) !?? Grundsatz: Thumbnails sind klein zu halten = sollten nicht als das große Bild übertragen werden sondern eine andere Datei sein, ganz einfach. Typische Lösung könnte sein: Pfad zum Bild: xyz/datei.jpg Pfad zum Thumbnail: xyz/thumbnail/datei.jpg . Solche Dinge sind IMHO eigentlich basics beim Gestalten von Tools oder Webseiten... Ich stimme Dir zu, dass klar sein sollte, dass man die Thumbnails verwendet. Aber leider ist das nicht so einfach mit dem Mediawiki. Man kann nicht einfach aus der Bild-URL die Thumbnail-URL berechnen. Das liegt daran, dass man Bilder aus Wikimedia Commons einbinden kann und da ist das alles etwas anders. Details weiss ich auch nicht mehr genau, aber ich hab in Taginfo extra einbauen müssen, dass er die Thumbnail-URL über die Wikimedia-API vom Server sich geben läßt, weil es nicht funktionierte nur die URL anzupassen. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Need help to fix? osm data in german
Keine Ahnung, warum der an mich geschrieben hat und was er will. Wenn jemand
sich berufen fühlt...
Jochen
- Forwarded message from Yves Pratter yves.prat...@gmail.com -
Date: Wed, 17 Dec 2014 11:16:18 +0100
From: Yves Pratter yves.prat...@gmail.com
To: Jochen Topf joc...@remote.org
Subject: Need help to fix? osm data in german
Hi,
I send you this message because I don’t understand your language. I see a lot
of objects with the same website and I check only one, but this is a wayside
cross.
I don’t think there is really a web server for one cross ;D
It’s probably a source:website. Could you talk to the user or send this to the
german community ?
Thanks,
—
Yves
Wegekreuz https://www.openstreetmap.org/node/391458035/history
{
type: node,
id: 391458035,
lat: 50.9439267,
lon: 6.0990637,
tags: {
addr:city: Übach - Palenberg,
addr:postcode: 52531,
addr:street: Wurmstraße / Heckstraße,
description: Werksteinkreuz mit Korpus, Korrektur Sockel in Kunststein
mit Marmorplatte und Inschrift wohl Anfang 20. Jahrhundert,
heritage: yes,
historic: wayside_cross,
image:
https://upload.wikimedia.org/wikipedia/commons/0/0f/%C3%9Cbach-Palenberg-Frelenberg_Denkmal-Nr._3%2C_Wurmstra%C3%9Fe%2C_Heckstra%C3%9Fe_%284944%29.jpg;,
name: Wegekreuz,
note: 50° 56' 37,5\ N 06° 05' 56,7\ O,
start_date: 1900,
website: www.limburg-bernd.de,
wikipedia: de:Liste der Baudenkmäler in Übach-Palenberg
}
},
http://overpass-turbo.eu/s/6zk http://overpass-turbo.eu/s/6zk
/*
This has been generated by the overpass-turbo wizard.
The original search was:
“website=www.limburg-bernd.de global”
*/
[out:json][timeout:25];
// gather results
(
// query part for: “website=www.limburg-bernd.de”
node[website=www.limburg-bernd.de];
way[website=www.limburg-bernd.de];
relation[website=www.limburg-bernd.de];
);
// print results
out body;
;
out skel qt;
- End forwarded message -
--
Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Private Insel
On So, Dez 14, 2014 at 05:22:26 +0100, Markus wrote: Wie kann man eine Insel bezeichnen, die in Privatbesitz ist? In Griechenland gibt einige solche Inseln. Sie sind aber trotzdem öffentlich zugänglich (Gesetz). Ich nehme mal an, Du fragst, wie man sie in OSM einträgt? Garnicht würde ich sagen. Wir tragen ja auch nicht an jeden Acker ein, ob er im Privatbesitz ist... Nicht-öffentliche Straßen und Wege können mit access=private getagged werden. Aber bei Flächen, Gebäuden, usw. ist das nicht üblich. Eigentlich kann man davon ausgehen, dass die meisten Flächen irgendwem gehören. Das ist bei ner Insel auch nicht anders... Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche OSM-Vertretung sinnvoll?
On Fr, Okt 24, 2014 at 09:45:50 +0200, Dietmar Seifert wrote: nein, die Fossgis vertritt in Deutschland unsere Interessen, wenn wir a) Spenden innerhalb Deutschlands sammeln und b) wenn jemand eine offzielle Unterschrift braucht Da unterschreibt aber hoffentlich keiner mit xyname OpenStreetMap Deutschland Eine deutsche OSM-Vertretung muß gewählt werden und die OSM Community repräsentieren. Wer von der Presse oder von Unternehmen wird bei der Fossgis nachfragen, um Kontakt zu OSM in Deutschland zu bekommen? Da wird am ehesten die Kontaktseite auf [2] verwendet, was auch aktuell gut ist, aber ich finde es gut, wenn wir uns mehr organisieren. Also bisher hat das ganz gut funktionert mit dem FOSSGIS als offizieller Vertretung. Was da genau draufsteht, ist so wichtig nicht. Joachim Kast redet seit Jahren mit Behörden und stellt sich als offizieller Ansprechpartner vor, ohne dass er ein gewähltes Amt hat. Das haben wir auf irgendeinem Treffen von aktiven OSMern mal so beschlossen, dass er das machen kann. (Nicht, dass er das davor nicht auch schon gemacht hätte. Wir haben ja eigentlich immer den Standpunkt vertreten, dass jeder, der sich berufen fühlt, auch einfach für die OSM-Community sprechen kann, auch ohne den offiziellen Posten. Das entspricht einfach dem Grassroots-Ansatz von OSM.) Und gelegentlich schlagen beim FOSSGIS wirklich auch Externe auf, die OSM ansprechen wollen. Klar wäre es schöner, wenn das alles gut geregelt ist und viele OSMer sich in einem Verein oder so engagieren und Leute wählen usw. Und ja, es wäre auch schön, wenn da auch irgendwie OSM draufsteht. Aber das Problem ist halt immer wieder gewesen, dass es nicht genug Aktive gibt. Ich hab mehrfach Treffen angeleiert, wo wir sowas in Gang bringen wollten. Aber da kommen dann immer ein paar Leute und nachher bleiben nicht viele übrig, die wirklich Arbeit machen. Die Zusammenarbeit mit dem FOSSGIS ist also auch einfach der Versuch, den Overhead zu minimieren. Aber vielleicht war das auch er falsche Ansatz und mehr OSMer würden sich mit einem OSM-Verein identifizieren, auf dem auch OSM drauf steht, und würden sich dann mehr einbringen. Also wenn das jemand angehen will, dann wäre das sicher einen Versuch wert. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Taginfo findet jetzt noch mehr Infos über Tags
Taginfo hat heute einen Update bekommen, der noch mehr Infos über die Nutzung von Tags integriert. Viele Projekte, die Tags nutzen, sind schon dabei, z.B. Nominatim, JOSM, iD, OSRM, und, besonders wichtig, die OSM Cheat Mug. Mehr Infos unter http://blog.jochentopf.com/2014-09-19-taginfo-integrates-more-data-sources.html Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo Google besser ist als OSM
Hi! On Sa, Aug 30, 2014 at 11:12:38 +0200, Stephan Knauss wrote: ich kann meinen Google vs. OSM Kartenvergleich nun weltweit anbieten. Damit sieht man schnell wo Google glaubt dass es Hauptstraßen gibt die bei OSM nicht verzeichnet sind. Oder andersrum: Gegenden in denen wir noch Straßen von Luftbildern übernehmen sollten. Ich habe das Ganze in meinem Blog beschrieben: http://www.technologyblog.de/2014/08/wo-fehlen-bei-openstreetmap-noch-daten/ Die Kurzform: Ihr seht auf der Karte die Google Hauptstraßen und Gewässer bei denen es in OSM keine Entsprechung gibt. In perfekt gemappten Gebieten ist die Karte dann grau. Wenn ihr eine Stelle genauer ansehen oder im Editor vom Luftbild abmalen wollt könnt ihr mit den Buttons auf der linken Seite den Bereich im Editor laden. Ich bevorzuge JOSM, sollte aber auch mit iD und Potlatch gehen. http://compare.osm-tools.org/ Beim Armchair mappen könnt ihr euch nun auf die wirklich wichtigen Straßen konzentrieren. Coole Karte. Ich mag vorallem die psychodelischen Bilder, die beim zoomen und rumschieben kurz zu sehen sind. :-) Problem ist, dass ich nicht sehr nahe ranzoomen kann und daher der Ausschnitt da, wo ich versucht hab, von der API immer als zu gross abgelehnt wurde und das Laden in den JOSM nicht klappt daher. Praktisch wäre auch, wenn man auf die OSM-Karte umstellen kann, dann kann man u.U. ohne das Laden in den Editor erkennen, wo man ein false positive hat. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grillfleisch-Automat
On Mo, Jun 30, 2014 at 10:35:19 +0200, Martin Koppenhoefer wrote: Am 30. Juni 2014 10:28 schrieb chris66 chris66...@gmx.de: amenity=vending_machine vending=bbq gem. Wikipedia: *Barbecue* (also *barbeque*, *BBQ* and *barbie*) is a cooking method and apparatus. D.h. vending=bbq ist mehrdeutig und könnte entweder heissen: verkauft einen Grill oder verkauft grill-service (so was wie: man gibt Grillgut rein und es kommt gegrillt wieder raus). Der vending-Wert sollte m.E. nicht sein: Grill sondern Grillgut. Leider scheint es im Englischen mal wieder kein passendes Wort für Grillgut zu geben, ggf. könnte man sich mit einer Konstruktion wie food_for_bbq behelfen. Wenn gleichzeitig auch Getränke verkauft werden (gleicher Automat oder ein anderer daneben), müsste man das evtl. noch erweitern. Ich bin dafür, dass alles aufgelistet wird, was in dem Automaten verkauft wird. Schließlich macht es einen erheblichen Unterschied, was auf dem Grill landet. Manch einer wird den langen Weg zu einem der drei Grillautomaten scheuen, wenn es dort kein gutes Rindfleisch gibt, sondern nur Schweinefleisch. Oder die Biersorte ist die falsche. Ich würde vorschlagen, diese Informationen in eine Relation zu verpacken: amenity=vending_maschine, type=sold_here, die members sind dann Nodes für die einzelnen Dinge, die verkauft werden. Die Nodes werden da verortet, wo die Dinge herkommen. So kann man dann leicht alle Automaten ermitteln, die Rindfleisch aus Argentinien verkaufen oder Bier aus der Lieblingsbrauerei. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mailinglisten
On So, Jun 08, 2014 at 04:15:55 +0200, Thorsten Alge wrote: ich würde für mich und andere Mapper der Region Harz gerne eine Mailingliste nutzen. Ich habe die Wiki-Seite[1] dazu gelesen und die die Listenverwalter angeschrieben. Leider erhalte ich keine Antwort. Auch nach einer weiteren Mail zwei Wochen später habe ich wiederholt keine Antwort erhalten. Ist die E-Mail Adresse listenverwal...@openstreetmap.de noch aktuell? An wen kann man sich wenden? Diverse deutsche OSM-Server-Dienste sind seit Jahren quasi nicht administriert. Ab und zu macht mal jemand was, aber viele Anfragen verschwinden im Nichts, weil sich keiner zuständig fühlt. Das ist eine sehr unbefriedigende Situation, aber die bisherigen Versuche, neue Admins zu finden, sind alle im Sand verlaufen. Ab und zu meldet sich mal jemand, was zu helfen, aber sie bleiben nicht lange. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Markierungen auf Sportplätzen
On Do, Jun 05, 2014 at 08:43:52 +, Sven Geggus wrote: Nun dachte ich mir aber man könnte ja marked=yes/no an die Felder kleben. Mir ist nicht klar, was marked genau bedeuten soll, aber es ist als Tag-Name auf jeden Fall viel zu generisch. So wie class und type und so. Wer oder was wird da markiert? Wenn man sowas will, dann bitte highway:marked oder hiking_route_marked oder was weiss ich. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern-Mapping
On Sa, Mai 24, 2014 at 09:52:16 +0200, Andre Hinrichs wrote: In Sachen Hausnummern-Mapping bin ich auf (mindestens) zwei Probleme gestoßen und ich bin mir sicher, dass andere auf die gleichen Probleme gestoßen sind und wüsste gerne, wie diese in der Regel gelöst werden. 1.) Fehlende Hausnummern: Bei meinen Mapping-Touren finde ich sehr häufig Häuser, an denen keine Hausnummern angebracht (oder nicht findbar) sind. Das gilt auch für Häuser, bei denen ich das Grundstück betreten wüsste, um die Hausnummer zu erfahren. Bisher habe ich bei solchen Häusern ein fixme-Tag angebracht und die Hausnummer nicht eingetragen. Nun häufen sich diese fixmes langsam und fangen an zu nerven, da sie nicht wirklich korrigiert werden können. Frage also: Wie geht man damit um? Lösung 1: Die eben genannte fixme-Lösung mit dem Problem, dass sich fixmes langsam häufen. Lösung 2: Einfach (wie bei der Interpolation) raten und eintragen und gut is. Lösung 3: Einen Knoten setzen und eine addr:interpolation-Linie verwenden. (Was macht man dann mit Hausnummern wie 4a, 5c usw.?) Lösung 4: Dem Hausbesitzer eine Nachricht zukommen lassen, dass er doch bitte eine Hausnummer anbringen möchte. Diese Lösung favorisiere ich derzeit, bastele jedoch noch an der Formulierung und weiß auch nicht, ob das so OK wäre. Lösung 5: Gleich dem Ordnungsamt Bescheid geben. Das fände ich schon böse... Lösung 6: Etwas, woran ich noch nicht gedacht habe. Wenn offensichtlich ist, um welche Nummer es sich handeln muss, dann würde ich die eintragen, wenn nicht, dann würde ich garnichts tun. Offensichtlich wäre das z.B. bei Häusern in einer Reihe, wo die links und rechts stehenden Häuser Nummern haben. Ein FIXME bringt eigentlich nichts, weil man ja auch ohne das sehen kann, dass das Haus keine Nummer hat. Um das zu unterscheiden von Gebäuden, die keine Adresse haben, sollte man wo möglich Gebäude ohne Adresse anders eintragen, z.B. als building=garage, wenn es eine Garage ist. Siehe dazu auch diese QA-Seite: http://qa.poole.ch/ Den Hausbesitzern eine Nachricht zukommen zu lassen ist schwierig. Den Haus*bewohnern* vielleicht, aber die sind ja nicht unbedingt die Besitzer und eben darum auch die falschen Ansprechpartner. Wahrscheinlich käme es vielen auch etwas komisch vor, so eine Nachricht im Briefkasten zu haben. Du könntest Dich natürlich mit dem lokalen Roten Kreuz oder der Feuerwehr zusammen tun und mit denen ein Formschreiben aufsetzen, dass sie empfehlen Hausnummern anzubringen, damit das Haus im Notfall schnell gefunden wird. Vielleicht freuen sich diese Organisationen, wenn man ihnen eine Hilfe anbietet, sowas zu verteilen. Oder Du redest mit dem Briefträger und läßt dir von ihm sagen, welche Nummern diese Häuser haben... 2.) Interpolation mit Häusern: Das addr:interpolation-Tag (odd oder even oder all) kann nur mit Nodes verwendet werden. Wenn Häuser jedoch als Gebäude eingetragen sind, kann dieses Tag nicht verwendet werden (oder doch?), da man keine Linie zwischen zwei Gebieten ziehen kann. Z.B. in Clausthal-Zellerfeld meldet der housenumer validator deshalb einige Fehler, die aus diesem Problem resultieren. Daher meine Frage, was ihr von einer interpolation-Relation halten würdet. Dort könnten dann auch Gebäude als Start- oder End-Punkt herhalten. Interpolationslinien waren immer nur als eine temporäre Maßnahme gedacht, um das mappen etwas schneller zu machen. Wo es Gebäude schon gibt, gibt es keinen Grund mehr, diese Gebäude nicht alle einzeln mit der richtigen Adresse zu versehen. Alles andere macht es nur unnötig kompliziert. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern-Mapping
On Sa, Mai 24, 2014 at 10:27:19 +0200, Andreas Neumann wrote: Lösung 5: Gleich dem Ordnungsamt Bescheid geben. Das fände ich schon böse... Das klingt böse, wäre aber der korrekte Weg. Zumal ich die verdutzten Gesichter im Ordnungsamt sehen möchte :D. Warum der korrekte Weg? Bei vielen Komunen ist es in einer Verordnung geregelt, dass jedes Grundstück eine von außen gut sichtbare Hausnummer haben muss. Leider halten sich, insbesondere auf den Vororten (wo doch jeder weiß, dass hier Nummer X ist), recht viele nicht an diese Anordnung. Also das finde ich jetzt doch sehr bedenklich, wenn sich Mapper hier als Hilfspolizisten aufschwingen. Dem Hausbesitzer vorzuschlagen, eine Hausnummer anzubringen, damit das Haus im Notfall schneller gefunden wird, das ist eine nette Hilfe, oder der Stadt zu melden, wenn man eine kaputte Straßenlaterne gefunden hat beim Mappen. Aber Leute anzuschwärzen, weil sie keine Hausnummer am Haus haben? Viele Leute haben eh schon Angst um ihre Privatssphäre, wenn sie mitbekommen, dass wir ihre Häuser mappen, wenn sie jetzt noch Angst haben müssen, dass wir hinter ihnen herspionieren, dann haben wir bald einen Rufe wie Google. :-) Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rad-Wander-Skate-Routen
On Do, Mai 22, 2014 at 01:51:45 +0200, C.Brause wrote: ich wollte mal eine ausgeschilderte Mehrzweckroute in der Nähe mappen. Mein Problem ist, dass sie sowohl für Radfahrer, als auch Wanderer und Skater ausgewiesen ist. Mein Ansatz wäre jetzt, die Route als Relation mit route=bicycle;hiking;inline_skates zu bezeichnen und den mir bekannten Renderern (opencyclemap und waymarks) den Hinweis geben, dass solche Wege auch aufgenommen werden könnten/sollten. Ein Blick auf Taginfo zeigt mir, dass solche Kombinationen insgesamt ca. 110 mal vorkommen. Gefunden habe ich aber auch Radrouten, bei denen die Zusatzinfo, dass es sich auch um eine Ausgewiesene Rundstrecke für Skater und Wanderer handelt, in description=* befindet. Zum Auswerten ist das natürlich kaum geeignet. Ich vermute, dass das so gelöst wurde, damit es wenigstens irgendwo auch zu sehen ist. Im Wiki findet sich nichts zu Routen, die für mehr als ein Fortbewegungsmittel ausgeschildert sind. Was haltet ihr von dem Semicolonansatz und dem Anschreiben der Renderer? Semicolons in tags sind sehr problematisch: http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wegenamen in Kleingärten
On So, Mai 18, 2014 at 04:34:57 +0200, Falk Zscheile wrote: Mein Vorschlag wäre der folgende: Kleingartenkolonien haben in der Regel auch eine echte Adresse. wenn man gleichzeitig neben dem Vorortnamen name=value noch addr:street=value setzt, kann man das Auswerten und für alle ein brauchbares Ergebnis erzielen. Bitte nicht. addr:street gehört an Nodes oder Buildings, die Adressen haben, nicht an Straßen. Allenfalls könnte man dem Vereinsheim, wenn es eins mit Adresse gibt, so was verpassen. Sonst wird hier noch mehr vermischt, was nicht zusammen gehört, und damit die Auswertung weiter erschwert. Ansonsten muss ich Falk Recht geben. Ggf. sollte beim Geocoding halt addr:street an Gebäude bevorzugt gefunden werden vor einem highway mit name. Oder man nimmt alle Wege raus, die in Kleingärten sind. Wir haben das selbe Problem noch bei vielen anderen Stellen. Es ist häufig nicht klar, auf was sich name bezieht. Ist das der Name eines Gebäudes oder der Name einer Firma im Gebäude oder der Name der einzigen Firmen im Gebäude? Wollen wir alle diese Dinge sauber unterscheiden, brauchen wir noch ne Menge mehr *_name Tags. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] BKG nutzt OSM Daten im Verfahren TopPlus
On Di, Mai 06, 2014 at 12:56:49 +0200, Stefan Keller wrote: Das Bundesamt für Kartographie und Geodäsie (BKG) nutzt OSM Daten - zusammen mit ihren (kostenpflichtigen bzw. nur Behörden zugänglichen?) Produkten! Das habe ich gefunden im aktuellen Heft der KN 2/2014 im Artikel TopPlus – von der detaillierten Stadtkarte bis zur europaweiten Übersichtskarte [1]. Man findet TopPlus auch auf den BKG-Seiten erwähnt. Ich werte das einerseits positiv, wird doch gesagt Um das Gebiet der Nachbarstaaten bis zu den höchsten Auflösungen darstellen zu können, werden OpenStreetMap-Daten verwendet. (...). Erst der Einsatz dieser Daten ermöglicht (aber) die Produktion von grenz-übergreifenden Karten großer Maßstäbe. Damit wird erstmals bei einem BKG-Produkt der Versuch unternommen, amtliche Daten und freie Daten in einem Produkt zu integrieren. Peter Kunz, von dem der Artikel ist, hat schon auf der FOSSGIS in Dessau einen Vortrag gehalten, wo er seine ersten Versuche dazu vorgestellt hat. Ich freue mich, dass da inzwischen anscheinend ein Produkt draus geworden ist. Hier habe ich noch einen Vortrag mit den Details dazu gefunden: http://www.ikg.uni-hannover.de/aga/fileadmin/aga/documents/pdf-files_aga2013/aga13_b1_3_kunz.pdf Nicht nur technisch sondern auch kartographisch hervorragend! Andererseits wundert's mich, wie das rechtlich aussieht (bin aber kein Jurist und will keine Debatte vom Zaun brechen...). Sollte unproblematisch sein, weil die Mischung erst im Endprodukt ist. Peter Kunz ist sich der Problematik auf jeden Fall bewußt, ich habe da selbst schon mit ihm drüber gesprochen, ich gehe also mal davon aus, dass er das mit dem Hausjuristen abgeklärt hat, bevor er ein offizielles BKG-Produkt daraus gemacht hat. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] BKG nutzt OSM Daten im Verfahren TopPlus
On Di, Mai 06, 2014 at 09:55:52 +0200, Stefan Keller wrote: Das klingt ja sehr interessant. @Jochen: Weisst du, ob der Style/die Symbologie unter einer freien Lizenz steht? Ich glaube nicht, dass der Style frei ist. Aber wenn jemand lieb fragt, vielleicht geben sie ihn ja raus. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit von OSM-Objekten
Technisch gesehen werden die Koordinaten mit 10 Millionen multipliziert und dann in einem Integer gespeichert, also die Nachkommastellen weggestrichen. Um die Koordinaten also mit der vollen Genauigkeit, die OSM bietet, darzustellen, braucht Du 7 Nachkommastellen. Jochen On Do, Feb 20, 2014 at 04:27:58 +0100, Markus wrote: Date: Thu, 20 Feb 2014 16:27:58 +0100 From: Markus liste12a4...@gmx.de To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: [Talk-de] Genauigkeit von OSM-Objekten Wie genau werden Koordinaten in OSM gespeichert? In der History in JOSM werden 6 Nachkommastellen angezeigt. 1° hat 60' à 1852m (auf dem Meridian) 1° entspricht also 110120m die 6. Nachkommastelle also 0,11m Ist das auch die Genauigkeit in der Datenbank? Falls nicht: wo/wie sieht man die genaue Koordinate eines Objektes? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Attribution bei Logos/Illustration?
Hi! ich denke in so einem Fall sollte man irgendwo im Zusammenhang an passender Stelle die Attribution anbringen. Z.b. bei einem Film im Abspann, bei einer Website auf der Impressums-Seite, bei einem Buch auf der Copyright-Seite oder bei einer Präsentation auf der letzten Folie. GGf. würde mir auch ein Hinweis auf einer Verpackung reichen, z.B. wenn man eine Tasse bedruckt und das Design nicht durch die Attribution zerstören will. Da ist mir dann die Nutzung von OSM in creative, productive, or unexpected ways wichtiger als die Attributionsregeln strikt auszulegen. Ein bischen gesunder Menschenverstand und guter Wille ist mir lieber als genaue Regelungen, die im Einzelfall dann doch nicht weiterhelfen. Und viele dieser Fälle gibt es ja nicht nur bei OSM. Z.B. ist es total üblich Copyrights im Abspann von Filmen zu zeigen, da wird das also auch jeder erwarten. Jochen On Di, Feb 18, 2014 at 02:38:15 +, Sven Geggus wrote: Date: Tue, 18 Feb 2014 14:38:15 + (UTC) From: Sven Geggus li...@fuchsschwanzdomain.de To: talk-de@openstreetmap.org Subject: [Talk-de] Attribution bei Logos/Illustration? Hallo zusammen, wie sieht denn das bei OSM mit der Attribution aus, wenn man OSM Daten zur Illustration verwendet? Oft kann man da ja kaum ein Copyright dazuschreiben ohne das Design komplett kaputt zu machen und meistens sind die OSM Daten bei sowas ja auch mehr dekoratives Beiwerk. Beispiel wäre eine OSM Karte als Webseitenhintergrund oder ein Logo das Kartenausschnitte enthät. http://mapnik.org/ hat zum Beispiel solche Kartenausschnitte auf seiner Startseite (ohne Attribution) Gruss Sven -- Um Kontrolle Ihres Kontos wiederzugewinnen, klicken Sie bitte auf das Verbindungsgebrüll. (aus einer Ebay fishing Mail) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import Mailingliste spielt verrueckt?
On Mi, Feb 05, 2014 at 10:56:21 +0100, Alexander Lehner wrote: ich bekomme gerade minutenweise (alle?) Posts der osm-import Mailingliste seit 2010. Geht's da nur mir so? Wurde auf dem IRC von jemandem angesprochen. Sollte gefixt sein. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vortrag von Jochen Topf zum OSM-Datenmodell in Hamburg
On Fri, Jan 17, 2014 at 10:42:39AM +0100, Jochen Topf wrote: Der Vortrag ist aufgezeichnet worden, allerdings ist unklar, ob der Ton gut genug rüber gekommen ist. Wenn die Aufzeichnung okay ist, dann werden wir die auch veröffentlichen. Die Aufzeichnung war leider untauglich. Ich hab die Folien hier [1] zur Verfügung gestellt, allerdings bringen die wahrscheinlich nicht viel ohne den Vortrag dazu. Jochen [1] http://media.jochentopf.com/media/2014-01-16-talk-hafencityuni-osm-datenmodell-de-slides.pdf -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bessere Nutzung der Wikinamensräume / Verbesserung der Wikisuche
On Fr, Jan 17, 2014 at 10:00:43 +0100, Holger Jeromin wrote: Nach Hören des aktuellen Podcasts und der Probleme der Suche des Taggings von Objekten habe ich eine Idee bekommen. Man sollte die Tag-Seiten pro Sprache in einen richtigen Wikimedia Namensraum verschieben, um sie per Suche einschränken zu können. http://wiki.openstreetmap.org/w/index.php?title=Special%3ASearchprofile=advancedfulltext=Searchredirs=1 Die aktuellen Namensräume mit dem DE: die dort auftauchen sind da nicht so hilfreich, weil ich nicht in der Sprache suchen will, sondern im Tag-Namensraum. Damit könnte man einschränken ob man Ergebnisse aus dem Raum Tag/TagEN, TagDE und TagFR erhalte, wenn ich diese Sprachen spreche. Sehe ich nicht, was das bringen soll. Ich hab im Wiki noch nie nur in einem Namensraum gesucht. Und die meisten Leute werden auch nicht wissen, wie das geht. Und es ist mir auch unklar, warum man nicht auch Resultate in einem anderen Namensraum finden will. Die im Podcast angesprochenen Probleme sollte sich anders lösen lassen. So richtig ist das im Podcast nicht rausgekommen, aber taginfo hat seit langr Zeit schon eine Volltextsuche der Wiki-Texte. So kann man z.B. nach preschool suchen und findet dann kindergarten: http://taginfo.openstreetmap.org/search?q=preschool#fulltext Aber diese Suche kann natürlich auch nur Begriffe finden, die im Wiki auf den Key- und Tag-Seiten vorkommen. Vorschule wird halt nicht gefunden, weil das zwar im Wiki vorkommt, aber nicht auf den Key/Tag-Seiten. Diese Volltextsuche habe ich mal schnell gehackt irgendwann, sie könnte noch deutlich ausgebaut werden mit einem Synonymwörterbuch usw. Leider habe ich da aber keine Zeit für. Vielleicht will sich da ja mal jemand dran versuchen. Weiterhin wäre es super, wenn das Template RelatedTerm noch mehr benutzt würde und damit Synonyme über die Suche gefunden würde: http://wiki.openstreetmap.org/wiki/Template:RelatedTerm Das wäre sicher nicht ganz falsch. Wichtig wäre aber überhaupt erstmal, dass alle Begriffe überhaupt irgendwo auf den Key/Tag-Seiten auftauchen, die man vielleicht suchen würde. Also auf http://wiki.openstreetmap.org/wiki/DE%3ATag%3Aamenity%3Dkindergarten sollte das Wort Vorschule halt irgendwo stehen. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vortrag von Jochen Topf zum OSM-Datenmodell in Hamburg
On Fr, Jan 17, 2014 at 09:23:27 +0100, Rick, Hamburg wrote: ich war gestern ganz in der Nähe, bin aber mangels Navi in der City-Nord orientierungslos herum geirrt und habe den Hörsaal schlicht nicht gefunden. Asche auf mein Haupt. Das tut mir leid. Die HafenCity ist da nur in provisorischen Räumlichkeiten und deshalb ist da nichts richtig ausgeschildert. Ich habs auch nicht gleich gefunden... Der Vortrag ist aufgezeichnet worden, allerdings ist unklar, ob der Ton gut genug rüber gekommen ist. Wenn die Aufzeichnung okay ist, dann werden wir die auch veröffentlichen. Auf jeden Fall danke an die Uni, dass sie den Vortrag nicht nur für die Studenten angeboten haben. Einige Mapper aus der lokalen Community haben den Weg dorthin gefunden und ich habe mich gefreut einige wieder zu sehen bzw. neu kennenzulernen. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
On Di, Jan 14, 2014 at 08:33:18 +0100, Peter Wendorff wrote: Das kann natürlich auch Teil der API sein, aber selbst wenn nicht ließe sich das vermutlich umsetzen. Die größte Hürde sehe ich in der Software, die die OSM-Daten anwendet, denn die muss mehrere Werte unterstützen - Renderer, Router, ... Wir mappen zwar nicht für [Anwendungsimplementierung X], aber viele Anwendungen, gerade Mapnik, OSRM etc. sind eben doch treibende Kraft dafür, dass Mapper großflächig Daten beisteuern und vor allem korrigieren; notfalls korrigieren in dem Sinne, dass [Anwendung X] dann wieder funktioniert. Das ist ein ganz wichtiger Punkt. Bevor man sich Gedanken darüber macht, wie die Daten in OSM besser modelliert werden könnten, sollte man schauen, mit welchen Daten die Anwendungen umgehen können. Die Hürde ist in sehr vielen Fällen im Moment nicht das OSM-Datenmodell. Das ist zwar umständlich in der Handhabung, aber es ist mächtiger als das, was üblicherweise in der späteren Verarbeitung verwendet wird. Konkret ist unsere Rendering-Toolchain zu begrenzt. Mit osm2pgsql und Mapnik kann man einfach diese Multivalued-ref-Tags und dergl. nicht ohne Tricks umsetzen. Deshalb sind alle Versuche, dieses Problem anzugehen, immer auf halber Strecke hängen geblieben. Das Ergebnis waren komplexe Script-Verhaue und gigantische Mapnik-Config-Files. Wenn wir soweit wären, dass die Rendering-Toolchain ganz selbstverständlich mit solchen refs umgehen kann, dann würde sich daraus auch ergeben, wie wir das bei OSM richtig taggen müssen bzw. ob wir eine Ergänzung des OSM-Datenmodells brauchen. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vortrag von Jochen Topf zum OSM-Datenmodell in Hamburg
On So, Jan 05, 2014 at 06:14:52 +, Michael Buege wrote: Zitat Johannes Kröger: am 16. Januar (Donnerstag) um 16:00 wird Jochen Topf an der Hafencity Uni in Hamburg einen Vortrag über das Datenmodell von OSM halten. [...] Die Hafencity Universität befindet sich nicht in der Hafencity, sondern im Moment noch in der City Nord (S1/11 Rübenkamp, U-Sengelmannstraße). Der Vortrag findet im D-Gebäude im Zelt statt: Ich hab auf die Schnelle nix auf deren Seite gefunden: darf man da einfach so hin oder wie sind dort die Teilnahmebedingungen für solche Vorträge? Ist für jeden offen. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RadioOSM: OSMDE024 Hörergemurmel
On Wed, Nov 20, 2013 at 08:06:24PM +0100, Martin Koppenhoefer wrote: Am 17. November 2013 01:50 schrieb mazderm...@googlemail.com: Hallo liebe OpenStreetMapper, die neuste Folge von RadioOSM - OSMDE024 Hörergemurmel - ist verfügbar und sollte in Kürze in euren Podcatchern auftauchen. bin ich der einzige, bei dem das nicht im Podcatcher aufgetaucht ist, oder gibt es evtl. ein Problem mit dem Feed? Bei mir hats problemlos funktioniert. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Visualisierung und Simulation von Geodaten! DRINGEND!
Sehr geehrte Frau Stauffer, da diese Mail absolut nichts mit OSM zu tun hat, haben Sie sie offenbar an die falsche Adresse geschickt. Gemäß Ihrem Disclaimer am Ende der Mail (Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.) bin ich so nett und sage Ihnen hiermit Bescheid und werde die Mail jetzt vernichten. Mit freundlichen Grüßen Jochen Topf On Wed, Nov 13, 2013 at 01:42:43PM +0100, Angelika Stauffer wrote: Date: Wed, 13 Nov 2013 13:42:43 +0100 (CET) From: Angelika Stauffer angelika.stauf...@ips-bremen.de To: talk-de@openstreetmap.org Subject: [Talk-de] Visualisierung und Simulation von Geodaten! DRINGEND! Guten Tag, ich wende mich mit folgendem Anliegen an die OSM-Community: Für ein spannendes Projekt im Raum Koblenz suchen wir dringend einen Mitarbbeiter auf freiberuflicher Basis oder in Festanstellung für die Simulation bzw. Visualisierung von Geodaten. Das Projekt dauert vorerst 18 Monate, mit Aussicht auf Verlängerung. Hier die genaue Tätigkeitsbeschreibung: Terrain-Datenbases: * Quelldatenbearbeitung mit ArcMap und ERDAS Imagine * Airfielderstellung mit CnAirG, AdaptiveBuild Multigen Creator sowie der Airfield-Libraries mit der INDRA-Software * Texturerstellung mit Adobe Photoshop * Erstellung und Verifikation von Visual-Datenbasen mit LITHOS * Erstellung von Radar-, NAVAIDS-, Prinipal-Feature-, GPWS-, SE Terrain-DBs mit interner Software von der Fa. INDRA * Erstellung von IOS/LPSG-Maps mit MapLink-Studio * Erstellen von ASTA-Datenbanken (Aircrew Synthetic Training Aids) Model-Datenbases: * Erstellung von 3D-Modellen mit Multigen-Creator * Erstellung von Modelperformance EW-Modellen mit der INDRA-Software TOOLS: * Generieung von ASTA-Databases * ArcMap * ERDAS Imagine * CnAirG * AdaptiveBuild Multigen Creator * Airfield Libraries * INDRA-Software * LITHOS * NAVAIDS Dabei ist die Beherrschung der Software nicht Vorraussetzung. Eine längere Einarbeitungszeit ist vorgesehen. Wichtig ist nur Erfahrung in der Bearbeitung von Geodaten und speziell in der Visualisierung. Wenn Interesse besteht, bitte ich um Kontaktaufnahme. Ich bin sowohl per Email als auch per Telefon erreichbar. Bitte schicken Sie dieses Angebot auch weiter, wenn Sie weitere Adressaten kennen für die dieses Angebot von Interesse sein könnte! Vielen Dank im Voraus!! Mit freundlichen Grüßen | Best regards, ANGELIKA STAUFFER Personalreferentin Recruiting | Professionals IPS GMBH Otto-Lilienthal-Straße 6 | 28199 Bremen fon +49 421 536 88 591 | fax +49 421 596 09 591 angelika.stauf...@ips-bremen.de | http://www.ips-bremen.de http://www.ips-bremen.de JOIN US ON [Xing] https://www.xing.com/profile/Angelika_Stauffer [Facebook] http://www.facebook.com/ipsbremen [Twitter] https://twitter.com/IPSBremen WEIHNACHTEN KOMMT SCHNELLER ALS MAN DENKT! Bleiben Sie trotzdem entspannt - Mit individuellen Weihnachtsgrüßen und originellen Geschenkideen vom ITN Weihnachtsservice. http://www.itn-bremen.de/content.php?pid=startseite/weihnachten.php Bei uns buchen Sie auch passende Räumlichkeiten für Jahresabschlussfeiern, Meetings und Mitarbeiteransprachen. Rechnungsanschrift: IPS GmbH | Otto-Lilienthal-Straße 6 | D-28199 Bremen Lieferanschrift: IPS GmbH | Georg-Wulf-Straße 13 | D-28199 Bremen Geschäftsführer: Subhash Chopra | Amtsgericht Bremen | HRB Nr. 12450 USt.-ID-Nr.: DE114417104 | Steuer-Nr.: 460 118 06226 IPS Vertriebsgesellschaft für innovative EDV-Produkte und -Systeme mbH Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, infor- mieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jetzt anmelden zum FOSSGIS Hacking Event vom 22.-24.11.2013 im Linuxhotel, Essen
On Wed, Jul 31, 2013 at 11:06:29AM +0200, Florian Lohoff wrote: On Tue, Jul 30, 2013 at 09:38:49PM +0200, Marco Lechner - FOSSGIS e.V. wrote: Hallo liebe Freunde der freien Software und freien Geodaten, nach erfolgter Terminfindung darf ich im Namen des FOSSGIS e.V. alle die dabei sein wollen und können zum Hacking Event im Linuxhotel einladen. Vom 22.-24. November 2013 treffen sich Communities und Interessierte aus freien GIS und Geodaten-Projekten im Linuxhotel in Essen, die jeweiligen Projekte voranzubringen aber insbesondere auch um Ideen und Neuigkeiten zwischen den Projekten auszutauschen. Das Event kann außerdem von FOSSGIS Mitgliedern als Arbeitswochenende zur Koordination von Vereinsaufgaben genutzt werden. Ich hätte Lust ein wenig an OSM Quality Assurance zu arbeiten. Sichworte OSRM, Postgis, Leaflet etc ... Ich habe da noch Ideen. Ich habe das Gefühl das OSMler da aber ein wenig die Exoten blieben - oder plant wer noch zu kommen? Für mich ist Essen jetzt auch nur 1 1/2 Stunden Weg. Wir haben ja in Karlsruhe ein relativ regelmäßiges OSM-Hackweekend, vielleicht bist Du da besser aufgehoben. Andererseits wäre es ja gerade gut, FOSSGIS und OSM mehr zu vermischen, also wenn Du mit Gutem Beispiel voran gehst, dann wollen vielleicht noch andere OSMer nach Essen kommen. Ich hab mir das auch schon überlegt, aber auch bei mir hängt es davon ab, was für andere Leute kommen. :-) Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
On Wed, Jul 10, 2013 at 12:20:02PM +0200, Martin Koppenhoefer wrote: Am 10. Juli 2013 00:50 schrieb Stephan Wolff s.wo...@web.de: Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag soll globale_id_pt = * (IFOPT Nummer) heißen. Ich finde den Namen globale_id_pt ungünstig (Denglish und nicht intuitiv verständlich). Warum nicht ref_ifopt? Die von anderen geäußerten Bedenken gegen diese Information teile ich nicht. sofern das öffentlich zugängliche Nummern sind, finde ich auch ref angemessen, oder ggf. ref:ifopt=* falls ref schon vergeben ist (z.B. durch Bahnhofsnummern der DB). globale_id_pt halte ich auch in jedem Fall für weniger gut geeignet, in OSM sind alphanumerische Identifier normalerweise ref oder ref:foo=* Ich hab mich immer gefragt, was der Informationsgehalt von diesem ref sein soll. Warum muss überall ref mit rein? Wie wäre es mit public_transport:ifopt oder so? public_transport ist als Key schon eingeführt und es wird sofort klar, dass es um ÖPNV geht irgendwie. Wer mehr wissen will, fragt seine Suchmaschine der Wahl nach ifopt und findet dann mehr. Allerdings scheint mir ifopt der Name eines Schemas zu sein und nicht der der ID. Also wahrscheinlich eher sowas wie public_transport:ifopt:stop_id oder so. globale_id_pt ist auf jeden Fall furchtbar. Es ist total unklar, was das ist und sein könnte, man findet nix gescheites, wenn man danach sucht und globale müßte global heissen, wenn es Englisch sein soll. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mapping in a digital world – ICA workshop
Hi! Vom 25. bis 30. August 2013 findet in Dresden die jährliche International Cartographic Conference statt. http://www.icc2013.org/ Der Eintritt ist recht teuer, aber es gibt am 24. August vor der Konferenz einen kostenlosen Workshop Mapping in a digital world, der von der ICA Commission on Map Design und der ICA Commission on Neocartography organisiert wird. Siehe http://neocartography.icaci.org/ Vielleicht interessier das den einen oder anderen. Short papers und lightning talks können dort auch noch eingereicht werden. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tags an Straßen
On Mon, Apr 08, 2013 at 03:24:44PM +0200, Heinz-Jürgen Oertel wrote:
Ich habe gesehen, dass ein neuer Mapper bei vielen Straßen,
gerade in meinem Bereich,
die Tags addr:{city,country,postcode,street} benutzt.
Ist das wirklich nötig? Oder zu viel der Informationen,
da ja meist schon implizit enthalten.
Das ist Quatsch. Diese Tags gehören nicht an Straßen sondern an Objekte, die
Adressen haben. Das sind in aller Regel Gebäude (als Punkt oder als Outline).
Straßen haben keine Adresse, sie haben nur einen Namen.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tags an Straßen
On Mon, Apr 08, 2013 at 05:34:07PM +0200, Martin Vonwald (imagic) wrote: Am 08.04.2013 um 17:05 schrieb Heinz-Jürgen Oertel hj.oer...@t-online.de: Wenn der User nicht die nächsten Tage antwortet, werde ich diese Attribute löschen. Lehn dich mal nicht zu weit aus dem Fenster. Auch wenn ich hier zustimme und ich(!) würde diese Daten auch nicht auf den Straßen eintragen, das Löschen von an sich korrekten Daten hat in OSM nichts verloren. Du (und auch ich) hast eine andere Meinung. Das ist aber nur eine Meinung. Solange die Daten nicht faktisch falsch sind hat niemand das Recht sie zu löschen. OSM ist kein jeder macht was er will-Projekt sondern ein Community-Projekt. Was solche Projekte angeht ist OSM ziemlich liberal und erlaubt mehr als das andere vielleicht würden. Aber das heisst nicht, dass man nicht so ein Mindestmaß an Gemeinsamkeit herstellen muss. Die faktische Richtigkeit von Daten ist da nur ein Kriterium. Worauf es ankommt ist ein grober Konsens, der im Projekt hergestellt wird (und der sich natürlich auch verändern kann über die Zeit). Und dieser Konsens sagt nunmal seit Erfindung der addr:*-Tags vor vielen Jahren, dass addr:*-Tags an Gebäude gehören und nicht an Straßen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Stand auf der Geoinformatik
Hi! Ich habe gerade von Prof. Zipf von der Uni Heidelberg eine Mail bekommen, dass es die Möglichkeit gibt auf der GEOINFORMATIK 2013 [1], die vom 13. bis 15.3. in Heidelberg stattfindet, kostenlos einen OSM-Stand zu bekommen. Wenn jemand das organisieren will, sollte er sehr bald Prof. Zipf (z...@uni-heidelberg.de) kontaktieren. Ich werde nicht dort sein, aber vielleicht gibts ja ein paar Leute, die eh da sind oder aus dem Heidelberger Raum, die das machen wollen. Jochen [1] http://geoinformatik2013.de/ -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stand auf der Geoinformatik
On Wed, Feb 27, 2013 at 10:36:54AM +0100, Pascal Neis wrote: Wieso bist du nicht da? Laut Programm[1] hältst du Do. morgen einen Vortrag. Es gab da etwas Durcheinander. Sieht wohl doch so aus, als ob ich da bin. Aber den Stand muss trotzdem jemand anders organisieren. :-) Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Turbo-Button in taginfo
Taginfo [1] hat jetzt zusätzlich zu den bisher schon existierenden XAPI- und JOSM-Buttons einen Turbo-Button, der die Turbo-Oberfläche [2] zur Overpass API [3] anspricht. Der Button mit dem Turbo-Symbol (das wie ein Lenkrad aussieht) findet sich rechts unter der Filter-Einstellung (die auch berücksichtigt wird) auf allen Key-, Tag-, und Relation-Seiten. Damit kann man z.B. sehr einfach alle Vorkommen eines Tags in einem Bereich finden und ggf. in weiteren Schritten auch in den JOSM laden. Z.B. hier: http://taginfo.openstreetmap.org/keys/amenity oder hier: http://taginfo.openstreetmap.org/tags/amenity=restaurant Vielen Dank an Martin Raifer für seine prima Overpass-Oberfläche und extra Dank, dass er die nötigen Funktionen eingebaut hat, dass ich das einfach von Taginfo aus ansprechen kann. Und natürlich danke an Roland Olbricht für die Overpass API. Die verschiedenen Tools, die verschiedene Leute so rund um OSM gebaut haben, sehen zwar oft nach einem komplizierten Flickenteppich aus, ich glaube, dass sie mit der Zeit alle mehr und mehr zusammenwachsen können, wenn wir in diese Tools Schnittstellen einbauen, mit denen sie zusammengesteckt werden können. Die Zusammenarbeit von Taginfo, Turbo und Overpass API ist so sicher noch nicht perfekt, aber es ist ein weiterer Schritt zu mehr Integration. Sagt uns, wie ihr diese Funktionen benutzt und wo wir vielleicht noch etwas besser machen können. Jochen [1] http://taginfo.openstreetmap.org/ [2] http://overpass-turbo.eu/ [3] http://wiki.osm.org/wiki/Overpass_API -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Sat, Feb 02, 2013 at 11:48:21AM +0100, Andreas Dommaschk wrote: die Demoseite scheint nicht mehr zu funktionieren. Jedenfalls werden hier keine Straßennamen mehr angezeigt http://mlm.jochentopf.com/?zoom=18lat=51.76091lon=14.32664layers=B0Tlang=de Doch, das funktioniert schon. Wahrscheinlich gibts an der Stelle halt keine name:de-Tags, sondern nur name-Tags, wie man das ja auch erwarten würde. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] QGIS mit OSM als Basis und Shapefile darüber nicht deckungsgleich!
On Mon, Jan 21, 2013 at 05:00:33PM +0100, Tom Müller wrote: leider bin ich kein GIS-Experte, aber vielleicht könnte Ihr mir ein wenig helfen! Ich habe in QGIS via OpenLayerPlugin die OSM-Karte quasi als Hintergrund. Nun habe ich einen weiteren Datensatz (Straßen als Shapefile), den ich gerne darüber anzeigen möchte. Leider scheinen die Koordinatensysteme (oder so) aber nicht kompatibel zu sein, jedenfalls decken sich die Straßen nicht. Ich habe dann mit einem anderen Plugin das Shape-Layer so verschoben, dass es an einem bestimmten Straßenabschnitt passt. Leider scheint es einfach unterschiedlich gestreckt zu sein, denn desto weiter ein Punkt von dieser Stelle entfernt ist, desto weiter entfernt liegt er von dem wo er sein sollte. Laut QGIS ist das KBS des SHP-Layers WGS 84 / UTM zone 48N (EPSG: 32648). Das OSM-Layer Google Mercator (EPSG: 900913). Hat jemand eine Idee wie ich das SHP-Layer entzerren kann? Damit QGIS Layer projiziert, die nicht zusammen passen, musst Du unter File - Project Properties im Tab Coordinate Reference System (CRS) Enable 'on the fly CRS' transformation anklicken und einstellen, welche Projektion Du willst. Zumindest in manchen QGIS-Versionen ist das nicht der Default. Dann müßte das eigentlich gehen, zumindest wenn in den Layern die Projektion jeweils korrekt erkannt wurde. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Küstenlinien
On Sat, Jan 19, 2013 at 11:07:08PM +0100, Oliver Raupach wrote: Am 19.01.2013 19:45, schrieb Jochen Topf: Das wird jede Nacht gebaut und dann verworfen, weil es zu viele Fehler gibt. Siehe http://tools.geofabrik.de/osmi/?view=coastline Ja, kenne ich. Bin auch manchmal dabei und korrigiere Fehler, die dort angezeigt werden. Aber es scheint endlos zu sein... Jopp. :-( Ich finde die Situation auch sehr unbefriedigend. OSM hat nunmal eine Größe erreicht, wo das simple gebt einfach mal irgendwelche Daten ein und dann machen wir schon was draus nicht mehr so gut funktioniert... Naja, ist es vielleicht mal Zeit eine gewisse Validierung der Daten beim Commit einzubauen? Könnte deine Prüfung bei jedem Commit laufen und die dort enthaltenen Daten überprüfen? Wenn alles stimmt werden die Daten angenommen und bei einem Fehler wird der Commit abgelehnt ( mit entsprechender Fehlermeldung und Hilfestellung natürlich...). Ich glaube auch, dass wir mehr Validierung beim Commit brauchen. Aber die Prüfungen, die OSMCoastline macht, sind dazu viel zu teuer. Mit der derzeitigen Datenstruktur geht das nicht. Da wird noch einiges an Gehirnschmalz und einiges an Änderungen nötig sein, bis wir das in den Griff bekommen. Ganz abgesehen davon, dass wir die richtige Balance finden müssen zwischen der gewünschten und sinnvollen Offenheit beim Tagging und der Validierung für das Nötigste. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Küstenlinien
On Sun, Jan 20, 2013 at 11:18:24AM +0100, Chris66 wrote: Am 19.01.2013 19:45, schrieb Jochen Topf: Das wird jede Nacht gebaut und dann verworfen, weil es zu viele Fehler gibt. Siehe http://tools.geofabrik.de/osmi/?view=coastline Hi Jochen, hier zB. kann ich in JOSM keinen Fehler erkennen: http://tools.geofabrik.de/osmi/?view=coastlinelon=55.30651lat=-21.23931zoom=15opacity=0.62overlays=coastline,coastline_error_lines,line_not_a_ring,line_overlap,line_invalid,line_direction,questionable,coastline_error_points,unconnected,intersections,not_a_ring,double_node,tagged_node Vielleicht hat's schon jemand gefixt. OSMI wird ja nur einmal täglich aktualisiert. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taginfo-Neuigkeiten
On Sun, Jan 20, 2013 at 11:29:53AM +0100, Christoph Hormann wrote: On Saturday 19 January 2013, Jochen Topf wrote: Eines der am häufigsten gewünschten Features für taginfo waren Statistiken über die Roles von Relation-Mitgliedern. Die gibt es nun. Genauer gesagt gibt es jetzt eine komplett neue Sektion, die sich mit Informationen zu den verschiedenen Relation-Typen beschäftigt. Hier gehts los: http://taginfo.openstreetmap.org/relations [...] Hallo Jochen, was mir schon vorher, aber auch gerade jetzt bei den Relationen aufgefallen ist, sind die vielen offensichtlichen Tippfehler, die man dabei sieht (minimale Variationen von einzelnen Einträgen) - wäre irgendwie schön, wenn man da einfacher zwecks Korrektur ran könnte - ein XAPI/JOSM link in jeder Zeile mit entsprechend niedriger Anzahl wäre praktisch, da die roles ja nicht wie die tags noch mal verlinkt sind. Dazu müßte in diesem Fall aber die XAPI (oder die Overpass API) nach Roles matchen können und das kann sie nicht. Allgemein hast Du aber recht: Es sollte einfacher sein, schnell durch viele Fälle mit Tippfehlern oder anderen Fehlern durchzugehen und sie zu korrigieren. So gnaz klar, wie das am besten aussehen könnte, ist mir das allerdings nicht. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taginfo-Neuigkeiten
On Sun, Jan 20, 2013 at 01:59:47PM +0100, Tobias Knerr wrote: Am 19.01.2013 16:18, schrieb Jochen Topf: Eines der am häufigsten gewünschten Features für taginfo waren Statistiken über die Roles von Relation-Mitgliedern. Die gibt es nun. Genauer gesagt gibt es jetzt eine komplett neue Sektion, die sich mit Informationen zu den verschiedenen Relation-Typen beschäftigt. Hier gehts los: http://taginfo.openstreetmap.org/relations Das sind coole Features, vielen Dank. :) Auch die neuen Grafiken sind gelungen - ich kannte diesen Diagrammtyp bisher nicht einmal, aber er lässt sich gut lesen. Marimekko chart nennt sich sowas. Was ich mir noch wünschen würde ist eine direkte Verlinkung zwischen der Tag-Seite für type=X mit der Relationsseite für die Relation X. Beispielsweise ist ja die Information, welche Tags an einem Relationstyp verwendet werden, nur indirekt über die Kombinationen auf der Tag-Seite des type zu erreichen. Umgekehrt kann die Suche, soweit ich sehe, nicht nach Relationstypen suchen. Da außerdem in den Relation:*-Seiten im Wiki die Statistiken für das jeweilige type-Tag angezeigt werden, wird man beim Recherchieren von Relationen wohl oft erst auf die Tag-Seite des type kommen. Ich hab jetzt sowohl die Suche erweitert, dass man auch nach Relation-Typen suchen kann als auch die Tag-Seite, dass es dort einen Link auf die Relation-Typ-Seite gibt, falls so ein Relation-Typ existiert. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Taginfo-Neuigkeiten
Eines der am häufigsten gewünschten Features für taginfo waren Statistiken über die Roles von Relation-Mitgliedern. Die gibt es nun. Genauer gesagt gibt es jetzt eine komplett neue Sektion, die sich mit Informationen zu den verschiedenen Relation-Typen beschäftigt. Hier gehts los: http://taginfo.openstreetmap.org/relations Teil dieser Seiten ist auch ein cooler neuer Grafik-Typ, der anzeigt, welche Roles auf welchen Typen von Relation-Mitgliedern es gibt. Zum Beispiel hier: http://taginfo.openstreetmap.org/relations/route#graph Die Beschreibung der Relation-Typen und die Bilder dazu kommen aus dem Wiki, genauer aus den Seiten der Form [SPRACHE:]Relation:TYP. Wenn ihr mehr Infos in diese Seiten einbaut, gibts auch mehr Infos auf taginfo. Die Suche findet nun auch die Roles. Alle diese Daten sind natürlich auch über die API zu erreichen. Neu ist auch, dass viele Funktionen auf den Seiten per Tastatur erreichbar sind. Vieles kann man also ohne Maus erledigen. Welche hotkeys es gibt seht ihr, wenn ihr auf den Hilfe-Link rechts unten klickt. Und wieder mal gab es viel aufzuräumen hinter den Kulissen, u.A. habe ich die meisten Javascript-Bibliotheken aktualisiert und z.B. das gerade veröffentlichte jQuery 1.9 eingebaut. Alle diese Änderungen bedeuten, dass die Übersetzungen der Texte für das User Interface unvollständig sind. Wenn Du helfen kannst, bestehende Übersetzungen zu ergänzen oder auch in neue Sprachen zu übersetzen, dann schau Dir diese Seite an und lege los: http://wiki.openstreetmap.org/wiki/Taginfo/I18N Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Küstenlinien
On Sat, Jan 19, 2013 at 07:13:38PM +0100, Oliver Raupach wrote: (Das File auf http://openstreetmapdata.com/ wird auch nur sehr selten gebaut. Woran liegt's? Sind die Fehler doch so schwer?) Das wird jede Nacht gebaut und dann verworfen, weil es zu viele Fehler gibt. Siehe http://tools.geofabrik.de/osmi/?view=coastline Ich finde die Situation auch sehr unbefriedigend. OSM hat nunmal eine Größe erreicht, wo das simple gebt einfach mal irgendwelche Daten ein und dann machen wir schon was draus nicht mehr so gut funktioniert... Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Multipolygone im Wiki
Wenn man die neue Interpretation zuläßt, dann gibts m.E. ein großes Problem: Wenn der Outer Ring komplett in einem Way ist, dann ist die Interpretation anders als wenn der Outer Ring das nicht ist, also auf mehrere Ways aufgeteilt ist. Im ersteren Fall kann der Way alleine ja keine Fläche umschließen. Diese Interpretation ist also wenig robust, weil das aufteilen eines Ways in einem Multipolygon ja durchaus nicht unüblich ist. (Bei linienhaften Tags auf dem outer ring tritt dieses Problem nicht auf, die sind okay.) Auch der nicht unübliche Fall, dass eine bestehende Fläche ohne Loch ein Loch bekommt, kann so leicht falsch gehandhabt werden. Nehmen wir an, wie haben einen Wald als geschlossenen Way eingetragen. Jemand entdeckt, dass da eine kleine Lichtung ist. Er nimmt den Way als outer in eine neue Relation, fügt einen inner way ein und denkt, er ist fertig. Aber das wäre er nach dieser neuen Interpretation halt nicht. Und wie ja Fred schon sagte, ist das eine neue Interpretation, die weder in der englischen Version der Wikiseite drin ist, noch meines Wissens sonst jemand bisher so verwendet hat. Und bestehende Daten uminterpretieren ist sehr problematisch. Letztlich muss man das Problem umgehen, in dem man members von multipolygon relations einfach nie tagged und alle Tags an die Relation tut. Nur dann kann man sich unabhängig von der Interpretation sicher sein, dass das richtige rauskommt. Jochen On Thu, Jan 10, 2013 at 04:40:36PM +0100, Ronnie Soak wrote: Date: Thu, 10 Jan 2013 16:40:36 +0100 From: Ronnie Soak chaoschaos0...@googlemail.com To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: Re: [Talk-de] Multipolygone im Wiki Klingt für mich eigentlich wie im Wiki beschrieben logischer. Deine Interpretation würde bedeuten, dass man keine Multipolygone aus Wegen bilden darf, die an sich schon eine vom Multipolygon abweichende Bedeutung haben. Diese Regel wäre mir bisher noch nicht bekannt gewesen. Die Alternative, nämlich einen zusätzlichen, ungetaggten aber deckungsgleichen Way zur exklusiven Nutzung im Multipolygon über die bestehende Waldgrenze zu zeichnen, halte ich für die schlechtere. My 2 cents Chaos Am 10.01.2013 16:20 schrieb Frederik Ramm frede...@remote.org: Hallo, ich wurde gerade auf diese Aenderung aufmerksam: http://wiki.openstreetmap.org/**w/index.php?title=DE%** 3ARelation%3Amultipolygon**action=historysubmitdiff=** 777558oldid=776557http://wiki.openstreetmap.org/w/index.php?title=DE%3ARelation%3Amultipolygonaction=historysubmitdiff=777558oldid=776557 Hier wurde bei den Multipolygonen das - voellig neue und zumindest in der englischen Version nicht vorhandene - Konzept eingefuehrt, dass Tags am aeusseren Ring eines Multipolygons fuer alles (inkl. aller Loecher) gelten, Tags an der Relation aber nur fuer den Bereich ohne Loecher. Zitat: Zum Beispiel kann die Außengrenze eines Waldes und eines Naturschutzgebietes identisch sein, wohingegen die Lichtung oder der See im Wald nicht zum Wald gehört, wohl aber Naturschutzgebiet. Hier wird das Muptipolygon als Wald beschrieben und die äußere Fläche als Naturschutzgebiet. Ich halte das fuer falsch; in meinen Augen sind Flaechentags am aeusseren Ring und solche an der Relation total gleichwertig (und letztere vorzuziehen); ein Bedeutungsunterschied existiert aber nicht. Kann ich das wieder in Einklang mit der englischen Fassung bringen, oder ist das, was da steht, ein Community-Konsens, der irgnedwie an mir vorbeigegangen ist? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 - End forwarded message - -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Taginfo Update
Hi! Ich hab taginfo etwas erweitert. Details unter http://blog.jochentopf.com/2013-01-10-taginfo-news.html . Wer taginfo noch nicht kennt: http://taginfo.openstreetmap.org/ Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Sat, Jan 05, 2013 at 01:24:21PM +0100, Max wrote: Am 03.12.2012 um 10:46 schrieb Martin Koppenhöfer dieterdre...@gmail.com: Am 03/dic/2012 um 10:32 schrieb Henning Scholland o...@aighes.de: Um bei obigem Beispiel zu bleiben: Es wird immer die Schlacht um Stalingrad sein, aber dennoch würde ich als deutschen Namen der aktuellen Stadt Wolgograd nutzen, weil die Stadt 1961 unbenannt wurde. Sehe ich auch so, daher nochmal der Hinweis auf old_name:de, bzw. bei komplexeren Fällen auch mit Jahreszahl. Ich fände es durchaus wünschenswert, auch mittlerweile ungebräuchliche Namen als solche gekennzeichnet in der dB zu haben. Es geht noch komplexer: von welcher Nation wurde von wann bis wann welcher Name verwendet? Wie soll Bratislava jetzt richtig getaggt werden? http://de.wikipedia.org/wiki/Bratislava#Namen Ich denke es ist klar, dass wir nicht alle Namen, die ein Ort über die Jahrtausende hatte, in OSM erfassen können. Ganz zu schweigen von den historischen Grenzen usw. Das OSM-Datenmodell ist einfach nicht mächtig genug, um das sinnvoll machen zu können. Und es ist auch nicht klar, ob wir die Community hätten, um das umsetzen zu können. Es ist halt schon was anderes, ob man vom Luftbild eine existierende Straße einzeichnet oder ob man irgendwie rausbekommt, wo mal eine Römerstraße war, die seither unter mehreren Schichten von Schutt verschwunden ist. Aus meiner Sicht kann der old_name nur dazu dienen, besonders bekannte und heute im allgemeinen Umgang noch teilweise benutzte ehemalige Namen bei OSM einzutragen. Und auch nur dann, wenn der Ort noch im wesentlichen der gleiche ist. Also finde ich es z.B. richtig Stalingrad als old_name einzutragen. Aus historischen Gründen ist diese Stadt nunmal mit diesem Namen verbunden und wird es auf lange Zeit sein. In Deutschland wird es wahrscheinlich mehr Leute geben, die mit dem Namen Stalingrad etwas anfangen können als mit Wolgograd. Es kann auch gut sein, dass z.B. jemand eine Reportage aus dem 2. Weltkrieg anschaut und dann mal auf die Karte guckt, wo diese Stadt ist. Anders ist das z.B. bei den Namen der alten römischen Kastellen, aus denen einige deutsche Städte (z.B. Köln) hervorgegangen sind. Die heutige Stadt hat fast nichts mehr gemein mit dem ursprünglichen Kastell und sicher war das damals kein place=city. Hier würde ich keinen old_name taggen. Ein anderes Beispiel ist Chemnitz, das ich mit old_name=Karl-Marx-Stadt taggen würde. Jetzt genau aufzuzeichnen, von wann bis wann Chemnitz diesen Namen hatte führt m.E. zu weit. Wenn man es unter dieser engeren Definition sieht, dann fällt mir kein Fall ein, wo mehr als ein old_name gebraucht wird bzw. wo die Jahreszahlen mit angegeben werden müßten. (Ich bin allerdings sicher, dass irgendjemand solche Fälle einfallen werden. :-) Wenn wir das Schema einfach halten, d.h. nur einen old_name erlauben und keine Jahreszahlen eintragen, dann ist die Chance viel höher, dass die Daten auch ausgewertet werden. Die beiden wesentlichen Anwendungen, nämlich die Suche unter dem alten Namen und eine Karte, bei der der alte Name nach dem neuen Namen in Klammern angegeben wird, sind damit möglich. Machen wir das Schema zu kompliziert, ist der Effekt nur, dass einfache Nutzungen unmöglich werden und kaum einer die schwierig zu verarbeitenden komplexen Daten auswertet. Hier noch eine schöne Animation wie sich die Grenzen in Europa seit 1000 AD verändert haben: http://www.wimp.com/presentday/ Nett. Da hat sich jemand viel Arbeit gemacht. :-) Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Sat, Dec 22, 2012 at 02:48:59PM +0100, hugin grimnirson wrote: Optional soll es auch eine Transliteration geben. noch besser ;-) obwohl ich mir das hart vorstellte, da mwn ja je nach zielsprache anders transliteriert wird. Ich mache es mir da einfach und benutze nur die Transliterationen, die die ICU-Bibliothek (www.icu-project.org) zur Verfügung stellt. Wer mehr braucht als die kann, muss dort ein feature request aufmachen. :-) Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Thu, Dec 20, 2012 at 12:06:37PM +0100, Christian Hauer wrote: Sorry, dass ich dieses Thema nochmals aufwärme, aber eine Frage an Jochen: Wenn die außer Gebrauch gekommenen deutschen Name jetzt - wie aufgrund dieses Threads zu erwarten - vermehrt in old_name:de umgewandelt werden: Wäre eine Auswertung und Aufnahme der old_name-Tags in die Karte mit vertretbarem Auswand möglich? Ich denke da bspw an eine Sprachauswahl in der Form von de|old:de|_. Ich bin zwar der Meinung, dass diese nicht in eine reguläre Karte gehören, die Möglichkeit einer historischen Karte würde ich allerdings sehr begrüßen. Ich habe eine flexiblere Sprachauswahl auf meiner ToDo-Liste. Dazu gehört auch, dass Tags wie int_name, old_name, usw. ausgewertet werden können. Optional soll es auch eine Transliteration geben. Und ich will die Art und Weise verbessern, wie man mehrere Labels in verschiedenen Sprachen haben kann. Dazu muss aber einiges an der Infrastruktur umgestellt werden und das dauert daher noch ein bischen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Projekt Multilingual Maps fertig
Das Wikipedia-Projekt Multilingual Maps ist fertig. Nunja, es gibt natürlich immer noch mehr Dinge zu tun. :-) Details in meinem Blog unter http://blog.jochentopf.com/2012-12-19-status-of-the-multilingual-maps-project.html Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Doppelt gemoppelte Landesnamen: Was tun?
Hi! Ich glaube das Problem wird sich ganz von selbst lösen, wenn die mehrsprachige Karte allgemeiner genutzt wird. Im Moment ist sie ja erst im Testbetrieb. Wir arbeiten dran, sie allgemeiner nutzbar zu machen. Wenn mehr und mehr Leute solche mehrsprachigen Karten anbieten bzw. nutzen, dann wird sich das glaube ich mit der Zeit auswachsen. Eventuell kann man das dann auch unterstützen indem man Tools baut, die verdächtige Namen finden, z.B. solche, die Klammern enthalten. In einigen Ländern ist ganz bewusst darauf gesetzt worden, mehrere Sprachen oder Schreibweisen im name-Tag unterzubringen. Das war meines Erachtens nicht richtig, aber durchaus verständlich vor dem Hintergrund, dass es eben nur eine Karte gab. Diese Entscheidungen kann man dann ja überdenken. Ich bin auch gerade am Schauen, wie ich eine automatische Transskiption in die mehrsprachige Karte einbauen kann. Das erfordert Änderungen am Mapnik und wird nicht von heute auf morgen passieren, aber erste Versuche waren sehr vielversprechend. Das ist meiner Meinung nach noch ein wichtiger Baustein, der uns fehlt. Jochen On Thu, Dec 13, 2012 at 09:38:31PM +0100, Wuzzy wrote: Date: Thu, 13 Dec 2012 21:38:31 +0100 From: Wuzzy wuz...@mail.ru To: talk-de@openstreetmap.org Subject: [Talk-de] Doppelt gemoppelte Landesnamen: Was tun? Was mir mit dem Herumspielen mit der mehrsprachigen Karte, die von Joto vorgestellt wurde, auffiel, ist die Tatsache, dass manche name=*-Tags quasi doppelt gemoppelt sind; d.h. dass der Name in diesen Keys in Landessprache _und_ der lateinischen Transkription angegeben wird. Überzeugt euch selbst: Macht mal »_|de« und guckt auf Afrika, insbesondere auf die Staaten Eritrea, Tschad, N'Djamena. Das doofe ist, dass diese Doppelmoppelei den Sinn einer mehrsprachigen Karte ganz fies verspottet. :( Ganz seltsam sehen bei »_|de« Algerien, Marokko und Algier aus. Erst in Landessprache untranskribiert, gefolgt von deutsch in selber Zeile, dann neue Zeile, und zwar transkribiert, aber nicht deutsch. Ich bin mir sicher, so war das sicherlich nicht gedacht. ;-) Dass beides in der selben Zeile auftauchen kann, war ja schon in der Mailingliste irgendwo erwähnt worden, aber diese kuriose Darstellung hat wohl noch niemand ausgemacht. Oder? Die doppelt gemoppelten Namen müssten mal aufgetrennt werden; ich halte es nicht für eine gute Idee, zwei Schreibvarianten des gleichen Namens im selben Key unterzubringen, gerade bei einer dynamischen mehrsprachigen Karte rächt sich das. Besonders lustig wird es dann, wenn eine links-nach-rechts und eine rechts-nach-links-Sprache im selben Tag auftaucht. Weiß jemand, wie man es besser manchen könnte? Der Witz ist, die mehrsprachige Karte dient schon jetzt auf unfreiwillige Weise als Qualitätssicherungswerkzeug. ;-) -- Wuzzy XMPP: wuz...@jabber.ccc.de E-Mail: wuz...@mail.ru ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Abfrage mit Gauß-Krüger-Koordinaten
On Sun, Dec 09, 2012 at 12:17:44AM +0100, Martin Trautmann wrote: kann man die OSM auch direkt mit Gauß-Krüger-Koordinaten aufrufen? Ich habe gerade mal http://raumplanung.tobwen.de/OSM/scripts/gk2wgs84.php?LAGE=DE_southRW=4478124.56HW=5500123.45 ausprobiert, wie auf http://wiki.openstreetmap.org/wiki/Gau%C3%9F-Kr%C3%BCger vorgeschlagen. Da kommt aber nur 'ne Fehlermeldung. Hab ich was falsch gemacht? Offenbar ist dieser Dienst halt einfach kaputt. Einfacher würde mir erscheinen, wenn man OSM-Karten auch direkt mit GKK anspringen könnte. Ist das möglich? Nein. GK sind nur eines von sehr vielen Koordinatensystemen. Auf meinem Rechner sind 3718 in der Konfig der proj.4-Bibliothek. Sollen die dann alle unterstützt werden? Wie würde man unterscheiden, welches Koordinatensystem gemeint ist? Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 29C3 (December 27th to 30th, 2012)
On Fri, Dec 07, 2012 at 09:26:38AM +0100, Gehling Marc wrote: Am 07.12.2012 um 00:42 schrieb Michael Kugelmann michaelk_...@gmx.de: Unsere Assembly-Planung sehe ich auch im OSM-Wiki bzw. hier auf der ML. Aber das Thema CCC muss zwangsweise im 28C3-Wiki laufen, sonst funktioniert es (leider) nicht (der CCC kann wahrlich nicht auf tausend Seiten nachforschen welche Bedarfe dass existieren). Vom Mass collaboration Projekt [1] habe ich die Anfrage bekommen, ob wir unsere Stände/Tische nahe beieinander haben wollen. Außerdem ob wir Vorträge, Panels oder Workshops machen. [1] https://events.ccc.de/congress/2012/wiki/Mass_collaboration Das sind offenbar die Leute, die das Wikidata-Projekt machen. Da gibts auf jeden Fall Dinge, wo wir zusammenarbeiten könnten und so. Also nahe beieinander macht Sinn. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 29C3 (December 27th to 30th, 2012)
On Thu, Dec 06, 2012 at 09:27:44PM +0100, Florian Lohoff wrote: On Wed, Nov 07, 2012 at 07:19:23AM +0100, Michael Kugelmann wrote: Hallo, da der Kartenvorverkauf für den 29C3 begonnen hat (siehe http://events.ccc.de/2012/11/03/ticket-vorverkauf-fur-den-29-chaos-communication-congress/): * gibt es bereits konkrete Pläne von OSM'lern dass sie hinfahren wollen? * besteht konkretes Interesse so etwas wie einen Projektstand zu machen und ggf. Workshops anzubieten? Ich werde auch auf dem 29C3 sein - Wenn es irgendwo eine erkennbare zusammenrottung von OSMlern gibt werde ich mich dazugesellen ;) Ich bin auch da. http://wiki.openstreetmap.org/wiki/Chaos_Communication_Congress/29C3 Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 29C3 (December 27th to 30th, 2012)
On Thu, Dec 06, 2012 at 10:09:58PM +0100, Michael Kugelmann wrote: Am 06.12.2012 21:27, schrieb Florian Lohoff: Ich werde auch auf dem 29C3 sein - Wenn es irgendwo eine erkennbare zusammenrottung von OSMlern gibt werde ich mich dazugesellen ;) http://events.ccc.de/congress/2012/wiki/OpenStreetMap = einfach einen Account im Wiki anlegen und in den Userdaten OpenStreetMap mit angeben = dann wird man automatisch aufgenommen. Ehrlich gesagt brauch ich nicht noch einen Account für noch ein Wiki... Wenn wir irgendwas organisieren wollen, dann sollten wir das in unserem Wiki machen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 29C3 - Organisation
On Fri, Dec 07, 2012 at 02:27:56AM +0100, Michael Kugelmann wrote: * es soll Assemblies geben statt traditioneller Projekttische-/Stände (siehe http://events.ccc.de/2012/10/22/assemblies/ ) * Karten habe ich bei Frederik angefragt (siehe Parallel-Email) * Flyer dito. Frage in die Runde (an die mitlesenden 29C3-Mapper): macht es Sinn den OSM-RollUp des FOSSGIS in HH zu haben? Ich weiß nicht wie es mit Wänden oder ähnliches in den Assemblies aussieht? Ich vermute dass man da etwas via Power-Strips befestigen kann (rückstandslos entfernbar). Aber dazu muss es überhaupt eine Wand an der Assembly geben. Der Ausweg könnte das RollUp sein das man auch frei im Raum stellen kann... (http://svn.openstreetmap.org/misc/pr_material/german_roll_up/osmrollup.pdf) Also wenn es keinen Aufwand macht, die mitzubringen, schad's auf jeden Fall nicht die da zu haben. Ich weiss aber nicht, wer die grad hat bzw. wo die grad sind. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom Level optimieren
On Tue, Dec 04, 2012 at 03:59:06PM +0100, Adrian Stabiszewski wrote: Douglas-Peucker sieht vielversprechend aus. Werde wohl aber eine Implementierung für Java selber schreiben müssen ;) http://www.vividsolutions.com/jts/jtshome.htm Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Verdrängung von Städten auf der Karte (war: Demo mehrsprachige Karte)
On Mon, Dec 03, 2012 at 02:41:00PM +0100, Tirkon wrote: Frage: Liegt eigentlich die gegenseitige Verdrängung der Kommunennamen auch im Einflussbereich oder geschieht dies woanders. Sie ist nämlich auf der Demokarte von der normalen Slippy Map verschieden. Die Anzeige dieser Namen ist nämlich derzeit sehr unbefriedigend. Da werden beispielsweise die Namen von Kleinstädten gerendert aber die angrenzender Landeshauptstädte nicht. Das klappt bei anderen Karten wesentlich besser und ist IMHO das augenfälligste Manko unseres Aushängeschildes Slippy Map. Auch die Städte Berlin, Hamburg und Bremen tauchen wegen des Stadtstaatenstatus erst sehr spät auf. Das violette Overlay des Bundeslandes ist hier kaum lesbar. Wir mögen uns an all dies schon gewöhnt haben aber Neuusern fällt das durchaus negativ auf. Derzeit ist die Reihenfolge, wer wen verdrängt quasi zufällig, dadurch kann es gut sein, dass das auf der Demokarte etwas anders aussieht. Glaub mir, das Problem ist allen, die Karten aus OSM-Daten machen, sehr bewusst. Aber es ist nicht einfach zu lösen. Das Problem ist, dass wir was das Kartenrendern angeht einen Punkt erreicht haben, wo alles, was man machen will, immer schwieriger wird und das Rendering der Karte immer langsamer macht. Jedes Problem, das man löst, wirft drei neue auf. Hier sind m.E. grundsätzlich neue Ideen gefordert. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Sun, Dec 02, 2012 at 03:45:02AM +0100, Stephan Knauss wrote: Gerrit writes: Zu Thailändisch o.ä. kann ich jetzt leider nichts sagen, da ich mich damit nicht auskenne. Der Font Loma von der Thai Linux Working Group ist GPL und sieht finde ich ganz gut aus: http://linux.thai.net/projects/thaifonts-scalable Habs grad probiert, aber da bekomme ich nur so Rechtecke statt der Zeichen. Keine Ahnung, warum. Wenns irgendjemand gibt, der sich mit Truetype Fonts und sowas gut auskennt, kann er sich ja mal melden. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bugfixes in der mehrsprachigen Karte
Hi! In der Kartenapplikation waren noch ein paar Fehler, die bei bestimmten Sprachkombinationen und Browsern aufgetreten sind. Die habe ich jetzt beseitigt. Außerdem habe ich die Art und Weise geändert, wie mehrere Sprachlabels angezeigt werden. Statt () wird jetzt [] benutzt. Damit ist es jetzt leichter zu unterscheiden, was aus dem Tag kommt und was von meiner Software. Wenn Ihr Euch z.B. Tokio auf dieser Karte anschaut: http://mlm.jochentopf.com/?zoom=6lat=35.35891lon=139.63965layers=B0Tlang=_%7Cde Zuerst kommt der japanische Name, dann (Tokyo), das ist noch im name-Tage mit drin. Und darunter das [Tokio] kommt aus dem name:de-Tag. Bevor ihr das ausprobiert, müßt ihr eventuell den Browsercache löschen. Manchmal erscheint der []-Name übrigens nach dem ersten Namen und manchmal darunter. Da ich in diesen Fällen nichts verschiedenes mache, muss das irgendwie daran liegen, wie Mapnik die labels rendert. Eventuell hat es was mit der links-nach-rechts- bzw. rechts-nach-links-Schreibweise der Schriften zu tun. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Mon, Dec 03, 2012 at 05:46:46AM +0100, Andreas Labres wrote: On 02.12.12 18:27, Martin Koppenhoefer wrote: m.E. ist z.B. Bratislava weitaus geläufiger als Pressburg, Geläufigkeit kannst aber nicht als Entscheidungskriterium nehmen. Wer entscheidet das? Wie alles bei OSM entscheidet das die Community. Das ist ja jetzt auch nicht gross anders als bei vielen anderen Problemen in OSM. Mit der Zeit bildet sich da schon ein Konsens raus. Klar wird es Problemfälle geben, aber wenn man sich nur auf die konzentriert, kommt man nie weiter. Man kann sich da ja auch ein bischen an diversen Quellen orientieren, z.B. gibt es eine offizielle Liste des Ständigen Ausschusses für geographische Namen (www.stagn.de) und man kann ja auch sehen, welchen Namen die Presse typischweise verwendet. Aber das sind auch nur Hinweise. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Mon, Dec 03, 2012 at 02:43:22AM +0100, Stephan Knauss wrote: Jochen Topf writes: On Sun, Dec 02, 2012 at 03:45:02AM +0100, Stephan Knauss wrote: Der Font Loma von der Thai Linux Working Group ist GPL und sieht finde ich ganz gut aus: http://linux.thai.net/projects/thaifonts-scalable Habs grad probiert, aber da bekomme ich nur so Rechtecke statt der Zeichen. Wird der Font bei Dir gefunden? Die Rechtecke kommen normalerweise wenn kein passender Glyph für das Zeichen da ist. Im Mapnik wiki gibt es ein kurzes Python script das die installierten Fonts auflistet. Ich vermute du hast entweder ein Verzeichnis erwischt in dem der Font nicht gesucht wird oder einen Tippfehler beim Fontnamen in Mapnik. Wenn der Font garnicht gefunden würde, dann müßten entweder keine Zeichen erscheinen oder er müßte auf den nächsten Font zurückfallen. Das ist aber nicht der Fall. Es waren genau alle Thai-Labels, die aus Rechtecken bestanden. Also hat er offenbar den Font gefunden, aber dann nicht verarbeiten können. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Sat, Dec 01, 2012 at 03:07:55AM +0100, Stephan Knauss wrote: Sven Geggus writes: Jochen Topf joc...@remote.org wrote: Also in Prosa. Man stelle mal auf de,en und zoome nach Chiang Mai (http://osm.org/go/4WxtSuJn) das sieht mit de,en in Jochens karte zumindest für mich erheblich lesbarer aus als in Thai Schrift. Der Font ist bei osm.org und Jochen leider so klein, dass niemand die Labels in Thai lesen kann. Da ist dann aber der Font dran Schuld. Wenn die Zeichen eines Alphabets kleiner sind als die eines anderen im gleichen Font, dann ist das halt inkonsistent. Gibt es einen anderen Font, der nur die Thai-Zeichen enthält und die größer darstellt bei gleicher Font-Size? Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Sat, Dec 01, 2012 at 10:53:00AM +0100, Stephan Knauss wrote: Jochen Topf writes: On Sat, Dec 01, 2012 at 03:07:55AM +0100, Stephan Knauss wrote: Der Font ist bei osm.org und Jochen leider so klein, dass niemand die Labels in Thai lesen kann. Da ist dann aber der Font dran Schuld. Wenn die Zeichen eines Alphabets kleiner sind als die eines anderen im gleichen Font, dann ist das halt inkonsistent. Ich vermute mal du verwendest die Font Kombination wie der offizielle Style mit DejaVu/Unifont. Da kommt dann alles was was Ja. latin-1 ist (auch die Ziffern) aus dem Vector Font DejaVu. Die restlichen Glyphen kommen aus dem Unifont als Bitmap. Das skaliert auch nicht so schön. Und die Größen der einzelnen Zeichen passen auch nicht zusammen. Kann man das dann nicht im Font anpassen? Also einen neuen Font basteln, der die Zeichen aus DejaVu und Unfont enthält, aber die Thai-Zeichen halt 20% größer? Ich hab keine Ahnung, wie die Fonts intern funktionieren. Also wenn da jemand was macht, bin ich gerne bereit auf der Karte mit verschiedenen Fonts oder so zu experimentieren. Aber mehr kann ich halt auch nicht machen. Gibt es einen anderen Font, der nur die Thai-Zeichen enthält und die größer darstellt bei gleicher Font-Size? Auf thaimap.osm-tools.org verwende ich den Font Loma. Dort sind die Zeichen auf eine einheitliche Höhe angepasst. Ich musste aber trotzdem die Fontsize um 1-2 Punkte erhöhen um alles lesbar zu bekommen. Falls du an Mapnik bastelst um den Font aus der Datenbank zu bekommen, dann wäre es klasse im gleichen Schritt auch die Fontsize anpassbar zu machen. Ich hab mal auf der Mapnik-Liste angefragt dazu, aber es gab noch keine Antwort. Wie ist es denn bei Chinesisch/Koreanisch? Sind da die kleinen Zeichen für Muttersprachler noch lesbar? Mapnik dreht dort die Zeichen ja auch auf den Straßenverlauf. Ist das so üblich, oder sollten die Zeichen immer aufrecht stehen? Wäre dann auch noch ein wichtiger Punkt für die asiatischen Sprachen. Welche Version von Mapnik verwendest du denn? Harfbuzz oder die letze offizielle? Mapnik 2.0 ausm Debian-Paket. Bei 2.1 war irgendwas anders, dass mein Code nicht tat, das muss ich nochmal genau untersuchen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Sat, Dec 01, 2012 at 12:15:03PM +0100, Gerrit wrote: Am 01.12.2012 11:04, schrieb Jochen Topf: Kann man das dann nicht im Font anpassen? Also einen neuen Font basteln, der die Zeichen aus DejaVu und Unfont enthält, aber die Thai-Zeichen halt 20% größer? Ich hab keine Ahnung, wie die Fonts intern funktionieren. Also wenn da jemand was macht, bin ich gerne bereit auf der Karte mit verschiedenen Fonts oder so zu experimentieren. Aber mehr kann ich halt auch nicht machen. Also ich würde das hier eher, wie es auch bei HTML funktioniert, mit den Sprachtags machen. Also dass für eine andere Sprache eine andere Schriftart genommen wird, anstatt alles in eine Schriftart zu quetschen. Das würde meine Sache mit Japanisch und Chinesisch möglich machen und wäre sicherlich auch einfacher zu warten. In HTML benutzt der Browser einfach je nach lang-Tag eine andere Schriftart. So etwas wäre in OSM auch am besten. Die name-tags sind doch schon vorhanden, die kann man doch für sowas prima nutzen. Wenn da name:th steht, wird einfach eine thailändische Schriftart genommen. Ich kann mir gar nicht vorstellen, dass es so schwierig ist, dem Renderer zu sagen, dass er bei jedem name:th einfach eine thailändische Schriftart nehmen soll. Ohne mich jetzt irgendwie aus dem Fenster lehnen zu wollen, aber ich glaube, das könnte sogar ich mit meinen allerwenigsten Programmierkenntnissen: if name==th font = thailändische Schriftart end if Oder nicht? Nein. So geht das leider nicht. Renderer sind komplex und haben ihre eigene Configfiles und man muss passende SQL-Queries schreiben und alles muss auch noch performant sein. Eventuell kann man in den Mapnik was einbauen, aber das ist nichts, was mal eben schnell geht. Wir haben hier auch irgendwie zwei Probleme: Das eine ist, passende Fonts zu bekommen, das andere ist, die in den Renderer reinzubekommen. Ersteres Problem kann nur jemand angehen, der diese Sprachen kann usw. Letzteres ist was für Programmierer. Kannst Du vielleicht mal irgendwo (z.B. im Wiki) aufschreiben, welche Fonts existieren und aus Deiner Sicht für welche Sprachen geeignet sind. Dazu Infos, was ggf. zu beachten ist, z.b. Font ist 20% zu klein im Vergleich zu latin1 DejaVu. Dann kannst Du schauen, ob man diese Fonts irgendwie neu zusammenstellen, vergrößern oder sonstwas kann, sodass sie im Renderer einfacher verwendet werden können. Ich habe ja schonmal bei den Mapnik-Leuten angefragt, wie man das vielleicht in die Software reinbekommt. Aber selbst wenn das geht, dann hilft das nichts, wenn wir dann eh keinen schönen Font haben. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Sat, Dec 01, 2012 at 12:32:00PM +0100, Falk Zscheile wrote: Am 1. Dezember 2012 12:15 schrieb Gerrit z0idb...@gmx.de: [Schriftschnitte für OSM-Karten] Also für Chinesisch und Japanisch kann ich zumindest sagen, dass die Schriftart unglaublich hässlich ist. Besonders das fehlende Hinting macht die Schrift unglaublich schlecht zu lesen. Leider gibt es aber nur sehr sehr wenige freie Schriftarten für die Sprachen, da die einfach so aufwendig zu machen sind. Dann noch eine freie Schriftart in guter Qualität zu finden ist fast ein Ding der Unmöglichkeit. In welchem Format muss die Schrift denn vorliegen, ggf. könnte man sich einmal in der LaTeX-Welt umschauen. Dort sollten sich eigentlich ansehnliche Schriften finden ... Also die Schriften, die sonst verwendet werden sind TrueType. Ob Mapnik auch noch andere unterstützt, weiss ich nicht. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Demo mehrsprachige Karte
Ich arbeite an einer mehrsprachigen Karte, also einer Karte auf der Du, der User, einstellen kannst, in welcher Sprache die Namen erscheinen sollen. Unter http://mlm.jochentopf.com/ gibts jetzt eine Demo. Die Tiles für diese Demo werden auf tile.openstreetmap.de gerechnet als Software kommt der Mapquest Render Stack mit einigen Änderungen von mir zu Einsatz. Du kannst jede beliebige Sprache oder Sprachkombination auswählen. Dies ist nur eine Demo-Seite, sie kann manchmal langsam sein oder auch garnicht funktionieren. Probierts aus und sagt mir, was Euch gefällt und was Euch nicht gefällt. Mehr über dieses Projekt unter http://wiki.openstreetmap.org/wiki/Multilingual_maps_Wikipedia_project Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Fri, Nov 30, 2012 at 04:05:06PM +0100, Martin Koppenhoefer wrote: Sieht ganz gut aus, ich habe mir die italienische Version angesehen. Was mir aufgefallen ist: in China habe ich viele chinesische Schriftzeichen, wo es auf englisch einen Text gäbe. Evtl. sollte man prüfen ob es Sinn macht. auch Rückfallsprachen zu definieren (ggf. auch mehrere, also z.B. italienisch, wenn's das nicht gibt spanisch, dann englisch, und dann name oder so) falls es für die gewählte Sprache keinen Eintrag gibt. Z.B. auch mit int_name als Alternative für englisch. Das kannst Du in dieser Demo ja von Hand machen. Wenn Du in das Eingabefeld it,es,en einträgst, dann geht er nacheinander diese Sprachen durch und als letzes dann den normalen name. Grundsätzlich wäre es super, wenn es eine (automatische oder crowd-datenbasierte) Transskription geben würde, um nicht-lateinische Schriftzeichen (z.B. arabisch, chinesisch, japanisch, div. indische etc.) halbwegs lesbar zu machen. Automatische Transliteration ist nicht immer so einfach, weil es häufig verschiedene Varianten gibt und so. Daher habe ich das jetzt erstmal außen vor gelassen. Und es ist auch nicht klar, wie das umgesetzt werden kann, weil man das wohl entweder ins osm2gsql oder in die PostreSQL einbauen müßte. Am besten wäre es m.E. für die meisten Karten, den Text sofern zutreffend zweisprachig zu bieten (Sprache des Users und name-Sprache), weil man vor Ort ja normalerweise nur die lokale Sprache vorfindet. Ich kann mal probieren, ob ich das als Variante anbieten kann. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Fri, Nov 30, 2012 at 05:37:37PM +0100, Gerrit wrote: Am 30.11.2012 15:38, schrieb Jochen Topf: Ich arbeite an einer mehrsprachigen Karte, also einer Karte auf der Du, der User, einstellen kannst, in welcher Sprache die Namen erscheinen sollen. Unter http://mlm.jochentopf.com/ gibts jetzt eine Demo. Die Tiles für diese Demo werden auf tile.openstreetmap.de gerechnet als Software kommt der Mapquest Render Stack mit einigen Änderungen von mir zu Einsatz. Du kannst jede beliebige Sprache oder Sprachkombination auswählen. Dies ist nur eine Demo-Seite, sie kann manchmal langsam sein oder auch garnicht funktionieren. Probierts aus und sagt mir, was Euch gefällt und was Euch nicht gefällt. Mehr über dieses Projekt unter http://wiki.openstreetmap.org/wiki/Multilingual_maps_Wikipedia_project Jochen Wow, echt super. So etwas habe ich mir schon immer für OSM gewünscht (und es sogar mal als Vorschlag geschrieben). Da muss ich dir wirklich aus vollstem Herzen meinen Dank aussprechen. Da jetzt die Beschriftungen ja anscheinend dynamisch generiert werden, hätte ich aber direkt einen Vorschlag (beim normalen OSM ist das leider auf taube Ohren gestoßen): Einige Sprachen würden besser mit einer anderen Schriftart aussehen. Ich sehe das im Moment für den Raum Japan, Korea, Taiwan, China: Die normale OSM-Schrift hat dort nur chinesische Zeichen, was das ganze in Japan etwas hässlich macht (Das Problem jetzt genauer auszuführen ist etwas schwierig, aber es sieht wirklich hässlich aus :D Wer interesse hat, hier ist ein ausführlicher Wikipedia-Artikel zu dem Problem http://de.wikipedia.org/wiki/Han-Vereinheitlichung). Naja, jedenfalls, wäre es vielleicht möglich, bei dem name:ja-Feld eine japanische Schriftart zu benutzen und bei name:ko eine koreanische? Für Chinesisch müsste ich noch mal gucken, das ist vielleicht name:zh-TW und name:zh-CN, aber da muss ich noch mal recherchieren. Aber das „wichtigste“ ist im Grunde erst einmal name:ja. Wäre das vielleicht möglich? Ich würde mal nach einer guten Open-Source-Schriftart für Japanisch suchen, falls Möglichkeit an Umsetzung besteht. Abhängig davon, welches name:*-Tag verwendet wurde, die Schriftart anders zu setzen, wäre sehr aufwändig. Dazu müßte man komplett neue Styles und Layer für jede Sprache anlegen. Das kostet viel Aufwand in der Pflege der Styles und Aufwand beim Rendern. Wenn man sowas machen will, dann müßte man den Mapnik erweitern, dass Fonts dynamisch anhand von Daten aus der Datenbank gesetzt werden können oder sowas. Wobei man dann immernoch im Datenbank-Query irgendwie rausfinden muss, welcher Font denn nun zum Einsatz kommen soll. Das erscheint mir recht schwierig bzw. aufwändig umzusetzen. Wenn es nicht abhängig vom Tag entschieden werden muss, sondern nur anhand der Unicode-Zeichen, dann wäre das machbar. Im Moment verwende ich den Deja Vu Font und wenn der ein Zeichen nicht hat den Unifont. Da könnte man schon z.B. einen dritten Font dazwischen tun, der für bestimmte Zeichen, die in Deja Vu nicht sind und die in Unifont nicht gut aussehen, bessere Glyphen hat. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Fri, Nov 30, 2012 at 05:28:38PM +0100, Christoph Hormann wrote: ich konnte auf den schnellen Blick nicht ganz eindeutig feststellen, ob das 'on demand' rendering nur die Texte austauscht oder auch die Namen neu positioniert. Zumindest scheinen je nach Sprachreihenfolge Namen nicht oder doch. Beispiel: zoomlevel 6, Niederlande bekomme ich bei 'de,en' ein Utrecht und bei 'en,de' nicht. Ich nehme an, da werden Namen eliminiert, für die kein Platz ist. Da wird komplett neu positioniert. Das ist nötig, weil die Labels ja in verschiedenen Sprachen verschieden lang sein können. Dadurch kann sowas wie von Dir beschrieben leicht passieren, dass ein Label in der einen Sprache da ist, aber in der anderen keinen Platz hat. Wenn tatsächlich die komplette Positionierung 'on demand' erfolgt, böte es sich auch an, andere Änderungen zu ermöglichen - beispielsweise die Anpassung der Schriftgröße. Das könnte man im Prinzip machen, ist aber die Frage, ob das wirklich sinnvoll ist. Der Kartograph, der die Karte designed hat, hat sich ja überlegt, wo er welche Schriftgrößen usw. verwendet. Z.B. sind die Beschriftungen bei Straßen vielleicht gerade so, dass sie über die Straßen-Linie passen. Wenn sie größer werden sieht das dann nimmer gut aus. Sinnvoll könnte das eventuell bei unterschiedlichen Schriftsystemen sein, mir scheinen z.B. die arabischen Schriftzeichen häufig eher zu niedrig zu sein. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Fri, Nov 30, 2012 at 04:09:28PM +, Sven Geggus wrote: Wenn ich aber im Sprachfeld de,en eintrage sieht das ja oft schon wirklich brauchbar aus. Könntest Du da noch einen Permalink einbauen, dann könnte man Vergleichs-URL posten. Ich habs ausprobiert: Angabe von zoom,lat,lon im URL funktioniert leider nicht. Permalink und URL parsen funktioniert jetzt. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
On Fri, Nov 30, 2012 at 07:33:16PM +0100, Christoph Hormann wrote: Das könnte man im Prinzip machen, ist aber die Frage, ob das wirklich sinnvoll ist. Der Kartograph, der die Karte designed hat, hat sich ja überlegt, wo er welche Schriftgrößen usw. verwendet. Z.B. sind die Beschriftungen bei Straßen vielleicht gerade so, dass sie über die Straßen-Linie passen. Wenn sie größer werden sieht das dann nimmer gut aus. Sinnvoll könnte das eventuell bei unterschiedlichen Schriftsystemen sein, mir scheinen z.B. die arabischen Schriftzeichen häufig eher zu niedrig zu sein. Meine Idee ist eigentlich - wenn man schon nicht die komplette Karte im rendering individuell nach der Auflösung des Ausgabemediums anpassen kann - das zumindest für die Elemente zu tun, die sowieso 'on demand' dargestellt werden. Wäre natürlich letztendlich nur ein Behelf. Ich denke, dass bei niedrigen zoom-Stufen Passungsprobleme wie Du sie schilderst nicht zu erwarten sind (ausgenommen implizite Annahmen in den Daten, also 'mapping for the renderer') - allerdings würden natürlich schon mehr Elemente wegfallen, wenn man die Schrift größer macht. Das ist ein ganze anderes Paar Schuhe. Für die Anpassung der Auflösung müßte man zumindest die Größe der Icons auch anpassen. Also das Problem muss jemand anderes angehen. :-) Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
