Re: [Talk-de] JOSM Bugs schließen
On Mon, 19 Jan 2009, Detlef Reichl wrote: und was machen wir z.B. mit http://josm.openstreetmap.de/ticket/506 ? Das Plug-in zu finden unter http://www.bigbob.org.uk/files/geotagged/ ist zum letzten mal 11-2007 aktualisiert worden. Bei der Entwicklungsgeschwindigkeit von JOSM bezweifle ich das es durch einen kleinen Fix wieder zum Laufen zu bringen ist. So gravierend sind die Änderungen nicht. Das ist alles korrigierbar. Einfach schließen und warten das jemand meckert? Nein. Was kann das Plugin denn, was die Alternativen nicht können? Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Bernd Wurst schrieb: Hallo. Am Montag, 19. Januar 2009 schrieb Carsten Schwede: Mein i3 mach grade eine Simulation, das funktioniert sehr schön. Vor ner Weile hab ich irgendwo gelesen, dass bisher nicht über Kachelgrenzen (~1x1°) hinweg geroutet werden kann. Ist das Problem mittlerweile behoben? In solchen Fällen scheint mein Etrex die Basemap zum Routing zu verwenden. Da mkgmap halt kachelweise arbeitet wüsste ich nicht wie sich das umgehen lassen könnte. Immerhin funktioniert die Differenzierung Auto/Fahrradrouting bei den Karten schonmal. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rekordhalter im Relationsfragmentieren
Hi! Karl Eichwalder schrieb: Übrigens ist der Rote Punkt auf Weiß jetzt sogar mit Namen Lillachquelle-Signalstein bereits seit ein paar Wochen mehr oder wenig fertig, aber nicht auf der Karte zu sehen; siehe auch: http://www.gnu.franken.de/ke/trips/2008/20081123-signalstein.html Taucht ebenfalls nicht als Route auf. Wie lautet den die Relation-ID? Ist aber korrekt als type=route;route=hiking verbucht: http://betaplace.emaitie.de/webapps.relation-analyzer/osm.jsp?relationId=5612 Die Relation hat keinen vernünftigen Namen. Nicht umsonst hatte ich doch jetzt geschrieben ;) Dann hast Du die Karte nicht genau gelesen: Da steht links: Daten vom 16.1. und in dem Stand ist sie noch namenlos. Im Namen steht das Symbol und der Name fehlt. Deshalb habe ich Lillachquelle-Signalstein aus Deiner vorigen Mail auch nicht gefunden, da steht nur roter punkt auf weißem Grund und davon gibt's verdammt viele. Ist doch erstmal schnuppe. Wo das vorkommt, mal es einfach hin (s. auch Bernds mail). Mit der zeit werden sich die fragmente schon zusammenfinden. Versuch doch bitte mal zu verstehen: Was grade eben passiert ist, war folgendes: 1. Du hast versucht, eine bestimmte Route anzusprechen 2. Du hast dafür selbst ganz intuitiv den Namen des Weges benutzt und keine ID genannt 3. Die Route war nicht aufzufinden, weil der Name nicht richtig getaggt war und das Symbol nicht eindeutig = Kommunikation erfolglos. Was ich besser fände wäre folgendes: 1. Du versuchst, eine bestimmte Route anzusprechen 2. Du nutzt dafür ganz intuitiv den Namen des Weges 3. Ich sehe im Datenbestand nach und finde die Route unter ihrem Namen = Route gefunden Das, genau das, ist der Grund, warum Routen einen Namen haben sollten. Damit Menschen darüber reden, sie wiederfinden und gmeinsam damit/daran arbeiten können. Jetzt klar? Genau auf dieses Problem wollte ich die ganze Zeit in der Namensdiskussion hinaus. :-) Der name ist optional. Nimm einfach alles, was als hiking/foot angelegt ist und render es mit einem default (meinetwegen mit fragezeichen). Wenn in symbol etwas verwertbares steht, verwende das stattdessen. Bei der CycleMap funktioniert das auch so. Meine Karte ist nicht die Cylcemap. Die Wanderkarte wird wesentlich weiter gehen und mehrere Komponenten haben: - slippy map - passende Garmin Karten - generiertes Wegeverzeichnis (derzeit noch testweise im Wiki) - Verzeichnis von POIs wie Wanderreitstationen Und ich werde definitiv nur Routen mit einer gewissen Mindestqualität rendern. Wenn der Sinn einer Relation nicht eindeutig erkennbar ist, sie nicht in eine menschenlesbare Wegeliste einsortiert werden kann (oder sie nur 7 Meter lang ist), dann hat sie auch noch nix auf der Karte verloren. Kopier' doch bitte das Symbol in symbol= und nenn' die Relation so, wie Du das gerade hier in der Mail getan hast. Dann landet die Route automatisch in der Vorschlagsliste vom Composer. Wie gesagt, z.t. ist das bereits geschehen. Detaillierte anpassungen werde ich erst vornehmen, wenn die internationale diskussion zu einer art ergebnis gekommen ist. Ich will aber niemanden abhalten, tätig zu werden, solange nicht einfach nur dinge gelöscht werden, die man nicht gebrauchen kann. Dann solltest Du sie demnächst auf der Karte bewundern dürfen. bye Nop [1] http://wiki.openstreetmap.org/wiki/Relation:route ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Natur- und Landschaftsschutzgebiet-Kart en für OSM
Moin ! kann mir einer sagen in wieweit die Definitionen für Natur- und Landschaftsschutzgebiete (siehe auch http://www.luebeck.de/bewohner/umwelt_gesundheit/naturschutz/schutzgebiete/schutzgebiete.html) in OSM übernommen werden können ?? Ich dachte hierbei an die visuelle Übertragung der Begrenzung. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Carsten Schwede computerte...@gmx.de wrote: Ja, das wäre eine Möglichkeit. Oder in QLandkarte, oder mit mkgmap selbst gehts auch. hast Du grade mal nen Kommandozeilenfluch für mich zur Hand, am besten gleich mit buntem Typ-File. Gruss Sven -- Der wichtigste Aspekt, den Sie vor der Entscheidung für ein Open Source-Betriebssystem bedenken sollten, ist, dass Sie kein Windows-Betriebssystem erhalten. (von http://www.dell.de/ubuntu) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte
Karl Eichwalder schrieb: Ekkehart ekkeh...@gmx.de writes: Komplexes Thema - Vereinfachte Darstellung - Keine Diskussionsgrundlage. Und wenn erstmal 2 durchgeritten sind, dann sagt der 3., das sieht aus wie ein reitweg -- da kann man reiten. Ich persönlich habe ja die illegalen Breschen im Nürnberger Reichswald schätzen gelernt, die die Mountainbiker quer durch die Bäume gebrochen haben. Da konnte ich immer sagen: Da ist schon ein Weg, den kann ich reiten, und mein Pferd liebt solche Hindernisstrecken. Der Flurschaden war eindeutig von 100en von Fahrrädern verursacht, da schimpft auch keiner auf die Reiter. :-) Nicht weniger ärgerlich sind freilich all die forstwirtschaftlichen fahrzeuge, die auch vor pfadartig angelegten Qualitätswanderwegen wie dem Frankenweg nicht haltmachen. Es mag sein, dass die forstwirtschaft die wege nach benutzung wiederherstellt. Das ändert aber nichts daran, dass wege oft monatelang verschlammt sind. Wäre das erste Mal, daß ich sowas erlebe. Normalerweise werden diese Wege nach dem Holzmachen sich selbst überlassen, hier in der Gegend sind welche jetzt schon 2 Jahre unpassierbar, weil einfach einen halben Meter hoch abgesägte Äste auf dem Weg liegen. Da räumt keiner auf. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Bernd Wurst be...@bwurst.org wrote: Ich glaub ich hol mir bald mal ein einfaches Nüvi weil ich unbedingt mal auf OSM-Daten im Auto geroutet werden will. ;-) Ich verfolge ja immer noch die Idee ein linuxbasiertes Navi (Garmin oder TomTom) mit alternativer Firmware auszustatten. Da sollte man mal nen Workshop machen, wenn jemand passende Geräte leihweise zur Verfügung stellt. Gruss Sven -- In the land of the brave and the free, we defend our freedom with the GNU GPL (Richard M. Stallman on www.gnu.org) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Hi, Sven Geggus schrieb: Ja, das wäre eine Möglichkeit. Oder in QLandkarte, oder mit mkgmap selbst gehts auch. hast Du grade mal nen Kommandozeilenfluch für mich zur Hand, am besten gleich mit buntem Typ-File. aehm sendmap.exe -l 61.img 6.2.img . typfile.typ Oder sendmap alleine starten, und dann durchklicken. -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Carsten Schwede computerte...@gmx.de wrote: aehm sendmap.exe -l 61.img 6.2.img . typfile.typ Oder sendmap alleine starten, und dann durchklicken. Ah stimmt ich erinnere mich nur die Windowsversion konnte korrekt mit dem Typfile umgehen :( Sven -- Software is like sex; it's better when it's free (Linus Torvalds) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Na dann hab ich doch gleich noch einen: Sven Geggus schrieb: Ah stimmt ich erinnere mich nur die Windowsversion konnte korrekt mit dem Typfile umgehen :( 1. Sendmap geht auch mit wine. (muss man aber nicht nutzen, da das Teil Probleme mit großen Mengen Dateien hat. 2. java -jar mkgmap.jar --gmapsupp *.img (Ich weiss jetzt aber nicht ob schon typ-Files gehen) -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Hallo. Am Dienstag, 20. Januar 2009 schrieb Chris-Hein Lunkhusen: Da mkgmap halt kachelweise arbeitet wüsste ich nicht wie sich das umgehen lassen könnte. Naja, aber es ist doch klar, dass das irgendwann gehen muss. Auch Garmin bekommt es hin, dass man über Kachelgrenzen drüber routen kann. Vielleicht müssen dazu irgendwelche IDs aneinander angepasst werden oder whatever. Das bekommen die schon noch irgendwann hin. Also ist die Antwort, dass das momentan weiterhin nicht geht? Die Basemap ist ja (ohne dass ich ein Garmin hätte) nichts was man als routingfähige Straßenkarte bezeichnen könnte, oder? Gruß, Bernd -- Es vergeht kein Tag an dem ich nicht alles wieder infrage stelle. - André Gide (frz. Schriftsteller) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Am 20. Januar 2009 10:25 schrieb Bernd Wurst be...@bwurst.org: Naja, aber es ist doch klar, dass das irgendwann gehen muss. Auch Garmin bekommt es hin, dass man über Kachelgrenzen drüber routen kann. Vielleicht müssen dazu irgendwelche IDs aneinander angepasst werden oder whatever. Das bekommen die schon noch irgendwann hin. Moin! Ich habe neulich mal die mkgmap-dev mailingliste durchgelesen, weil mich interessierte, wie viel da im Moment passiert. Hier http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2008q4/000145.html ist ein commit beschrieben, der NOD3-Nodes an den Kachelgrenzen möglich macht, die für das routing über diese hinweg gebraucht werden. Irgendwo anders stand auch, daß dies das einzige sei, was dafür nötig wäre und das routen über Kachelgrenzen jetzt einigermaßen zuverlässig funktioniere... @Carsten: Ich habe versucht, in qlandkartegt alle Kacheln auszuwählen und als gmapsupp.img zu exportieren. Die resultierende Datei ist auch über 500mb groß, aber ich kann z.B. bei Köln ab 7° östlich auf meinem Garmin etrex Vista keine Objekte auswählen und auch nicht routen (westlich 7° innerhalb Kölns funktionert es...). Ich war schon in qlandkartegt skeptisch, weil es nicht so aussah, als seien wirklich alle Kacheln gewählt, aber da die Dateigröße stimmte... MfG, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
On Tue, Jan 20, 2009 at 08:03:39AM +0100, Bernd Wurst wrote: Ach ja: Weißt du ob deine toolchain nahe beinander liegende Nodes zusammenzieht? Das erste Tool das OSM nach MP konvertiert hat und dabei routingfähig war, hatte das AFAIK gemacht. Als Mapper ist es mir wichtig zu wissen ob die Verbindungen an manchen Stellen kaputt sind oder nicht. Jo - Ich hatte Radomir auch mal angemailt er moege doch auch eine unmodifizierte karte anbieten - Ich finde diese konvertierbugbehebung eher kontraproduktiv. So werden fehler nie gefunden. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehler auf der Wiki-Seite der Wanderweg e für den Jurasteig
Hallo Jan, danke für den Hinweis! Da hatte ich wohl beim Wiki-Kopieren einen Fehler gemacht. Ist nun berichtigt. Stefan Jan Tappenbeck schrieb: Moin ! auf der Wanderwege-Seite (http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Wanderwege-Netz) sind zwei Relationen für die einzelnen Abschnitte des Jurasteigs (http://www.openstreetmap.org/browse/relation/49759) definiert. Etappe 2 und 3 haben nur dieselbe Relations-ID (http://www.openstreetmap.org/browse/relation/37505) - kann sich ein ortskundiger der Sache einmal annehmen ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen in großen Wanderwegen die sic h überlagern
Hallo Karl, hallo Jan, wenn Alprandweg und Frankenweg kilometerlang dieselbe route nehmen Ich würde das so machen wie bei den Grenzen: - Realation Aplrandweg - Relation Frankenweg - gemeinsame Wegstücke gehören zu beiden Relationen Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Adress Inspector
Frederik Ramm wrote: Wenn Du Hollabrunn ein country=at gibst, wird das aufhören. Wie ist das gemeint? Bei jedem Objekt mit Adresse ein addr:country=at dazu? Oder kann man global sagen Hollabrunn ist country=at (bzw. Wien ist country=at)? Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
2009/1/20 Florian Lohoff f...@rfc822.org On Tue, Jan 20, 2009 at 08:03:39AM +0100, Bernd Wurst wrote: Ach ja: Weißt du ob deine toolchain nahe beinander liegende Nodes zusammenzieht? Das erste Tool das OSM nach MP konvertiert hat und dabei routingfähig war, hatte das AFAIK gemacht. Als Mapper ist es mir wichtig zu wissen ob die Verbindungen an manchen Stellen kaputt sind oder nicht. Jo - Ich hatte Radomir auch mal angemailt er moege doch auch eine unmodifizierte karte anbieten - Ich finde diese konvertierbugbehebung eher kontraproduktiv. So werden fehler nie gefunden. Flo -- ja, und gravierender: neue entstehen, die in den Daten gar nicht enthalten sind. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen in großen Wanderwegen die sich überlagern
Hallo Bernd, Tagesetappe Was eine Tagesetappe ist ist etwas sehr Subjektives. (ausser vielleicht bei explizit so angelegten Routen mit entsprechenden Herbergen und organisiertem Gepäcktransport dazwischen) Eine Relation willkürlich aufzuteilen fände ich nicht besonders hilfreich. Falls die SW das nicht handhaben kann (?) müsste die Lösung hinter dem User-Interface geschehen. Aber Ländergrenzen beispielsweise funktionieren doch auch? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] mkgmap Größen begrenzt
Moin ! weiß einer von Euch, ob mkgmap in der Größe der Verarbeitung begrenzt ist. Hamburg.osm (44 mb) hat funktioniert / Schleswig-Holstein.osm (108 mb) ist abgebrochen - mit javameldungen auf dem bildschirm ! gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mkgmap Größen begrenzt
Moin, Jan Tappenbeck schrieb: weiß einer von Euch, ob mkgmap in der Größe der Verarbeitung begrenzt ist. Ja. Hamburg.osm (44 mb) hat funktioniert / Schleswig-Holstein.osm (108 mb) ist abgebrochen - mit javameldungen auf dem bildschirm ! Daran liegt es aber sicher nicht (mein größtes osm-File ist 1012MB), ich denke die Xmx-Option sollte bei Deinem java etwas höhergestellt werden. Allgemein empfiehlt es sich auch die 64bit-Version von Java zu verwenden, da kann der Heapspeicher bis knapp unter 4GB eingestellt werden. -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mkgmap Größen begrenzt
Hallo Carsten, vielen Dank für den Hinweis. Hast Du einen Link für die 64bit-Version von Java ? Auf http://www.java.com/de/download/manual.jsp finde ich keine 64bit-Angabe ! (WINDOWS VISTA) Gruß Jan :-) Carsten Schwede schrieb: Moin, Jan Tappenbeck schrieb: weiß einer von Euch, ob mkgmap in der Größe der Verarbeitung begrenzt ist. Ja. Hamburg.osm (44 mb) hat funktioniert / Schleswig-Holstein.osm (108 mb) ist abgebrochen - mit javameldungen auf dem bildschirm ! Daran liegt es aber sicher nicht (mein größtes osm-File ist 1012MB), ich denke die Xmx-Option sollte bei Deinem java etwas höhergestellt werden. Allgemein empfiehlt es sich auch die 64bit-Version von Java zu verwenden, da kann der Heapspeicher bis knapp unter 4GB eingestellt werden. -- Freundliche Grüße Jan Tappenbeck --- OpenStreetMap (OSM) - das FREIE Kartenprojekt http://www.openstreetmap.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mkgmap Größen begrenzt
Hi Jan, Jan Tappenbeck schrieb: Hast Du einen Link für die 64bit-Version von Java ? Ein Link funktioniert nicht. Gehe einfach auf http://java.sun.com/ klicke rechts im mittleren blauen Textkasten auf Java SE, wähle Deine bevorzugte Version aus, z.B. Java SE Development Kit (JDK) 6 Update 11 und klicke auf den Download-Button.m Danach kannst Du in einer Dropdown-Box Windows64 auswählen und darunter Multilanguage. Natürlich musst Du den Haken bei I Agree... machen und schon kannst Du über continue Java in der 64bit-Version downloaden. :-) Ich muss jetzt aber auch gleich wieder davon abraten, es gibt in dieser Version kein Java Web Start und kein Browserplugin. Unter Linux kann man das Ganze parallel zu einer 32bit-Version installieren, ob das in Windows geht kann ich nicht sagen. -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Adress Inspector
Andreas Labres wrote: Frederik Ramm wrote: Wenn Du Hollabrunn ein country=at gibst, wird das aufhören. Wie ist das gemeint? Bei jedem Objekt mit Adresse ein addr:country=at dazu? Oder kann man global sagen Hollabrunn ist country=at (bzw. Wien ist country=at)? Was ich im Wiki gesehen hab, ist addr:country optional bei Nodes und/oder Ways zu setzen. Von dem her, würd ich annehmen, dass es bei jedem Address Node auch gesetzt wird (was ich derzeit auch tu). Norbert smime.p7s Description: S/MIME Cryptographic Signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mkgmap Größen begrenzt
-Xmx512M hat ausgereicht ! gruß Jan :-) Carsten Schwede schrieb: Hi Jan, Jan Tappenbeck schrieb: Hast Du einen Link für die 64bit-Version von Java ? Ein Link funktioniert nicht. Gehe einfach auf http://java.sun.com/ klicke rechts im mittleren blauen Textkasten auf Java SE, wähle Deine bevorzugte Version aus, z.B. Java SE Development Kit (JDK) 6 Update 11 und klicke auf den Download-Button.m Danach kannst Du in einer Dropdown-Box Windows64 auswählen und darunter Multilanguage. Natürlich musst Du den Haken bei I Agree... machen und schon kannst Du über continue Java in der 64bit-Version downloaden. :-) Ich muss jetzt aber auch gleich wieder davon abraten, es gibt in dieser Version kein Java Web Start und kein Browserplugin. Unter Linux kann man das Ganze parallel zu einer 32bit-Version installieren, ob das in Windows geht kann ich nicht sagen. -- Freundliche Grüße Jan Tappenbeck --- OpenStreetMap (OSM) - das FREIE Kartenprojekt http://www.openstreetmap.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Adress Inspector
Frederik Ramm wrote: Wenn Du Hollabrunn ein country=at gibst, wird das aufhören. Wie ist das gemeint? Bei jedem Objekt mit Adresse ein addr:country=at dazu? Oder kann man global sagen Hollabrunn ist country=at (bzw. Wien ist country=at)? Servus, Andreas gemeint ist je Einzeladresse - wenn es viele sind kann ichs automatisieren lg Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Adress Inspector
Hallo, Andreas Labres wrote: Frederik Ramm wrote: Wenn Du Hollabrunn ein country=at gibst, wird das aufhören. Wie ist das gemeint? Bei jedem Objekt mit Adresse ein addr:country=at dazu? Genau! Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] API-Umstellung 20.-23. Maerz
Hallo, in der Zeit vom 20. bis 23. Maerz 2009 soll die API von 0.5 auf 0.6 umgestellt werden. In dieser Zeit sind werden keine Logins, keine Uploads/Downloads moeglich sein. Die Tileserver werden weiterhin funktionieren. Ebenso read-only-mirrors. Bitte notiert Euch den Termin und vermeidet es, an diesem verlaengerten Wochenende eine Mapping Party anzuberaumen ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Bugs schließen
Am Dienstag, den 20.01.2009, 09:06 +0100 schrieb Dirk Stöcker: On Mon, 19 Jan 2009, Detlef Reichl wrote: und was machen wir z.B. mit http://josm.openstreetmap.de/ticket/506 ? Das Plug-in zu finden unter http://www.bigbob.org.uk/files/geotagged/ ist zum letzten mal 11-2007 aktualisiert worden. Bei der Entwicklungsgeschwindigkeit von JOSM bezweifle ich das es durch einen kleinen Fix wieder zum Laufen zu bringen ist. So gravierend sind die Änderungen nicht. Das ist alles korrigierbar. Einfach schließen und warten das jemand meckert? Nein. Was kann das Plugin denn, was die Alternativen nicht können? Hallo, was es kann, kann ich nicht zu 100% sagen, da ich keine Doku gefunden habe. Der Source basiert laut einem Kommentar auf dem GeoImageLayer-Code und sieht auch aus wie eine abgespeckte oder alte Version davon. Als erweiterte Funktion wurde wohl mal versucht eine Sound-Ausgabe einzubauen, allerdings gibt es dazu nur ein winziges auskommentiertes Codefragment. Wenn man das Plug-in wieder zum Laufen bekäme dürfte es aussehen wie der GeoImageLayer, also keinerlei Mehrwert. Grüßle, detlef ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Adress Inspector
Frederik Ramm wrote: Andreas Labres wrote: Frederik Ramm wrote: Wenn Du Hollabrunn ein country=at gibst, wird das aufhören. Wie ist das gemeint? Bei jedem Objekt mit Adresse ein addr:country=at dazu? Genau! Mit Verlaub, aber wieviele Staaten gibt es glaubst Du auf dieser Welt mit plz=2020 und city=Hollabrunn? Noch dazu in diesen LängenBreiten... Irgendwo ist da im Konzept ein eigentlich ist fast alles optional, aber wenn Du nicht alles haarklein angibst, funktioniert der OSMI nicht mismatch... ;) Ich lasse mir noch alles einreden, daß Straße+Hausnummer+PLZ+Ort zusammen (mit Ausnahmen) notwendig sind, um eine vollständige Adresse anzugeben. Aber der Staat muß von woanders kommen... Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Adress Inspector
On Tue, Jan 20, 2009 at 11:56:11AM +0100, Andreas Labres wrote: Frederik Ramm wrote: Wenn Du Hollabrunn ein country=at gibst, wird das aufhören. Wie ist das gemeint? Bei jedem Objekt mit Adresse ein addr:country=at dazu? Oder kann man global sagen Hollabrunn ist country=at (bzw. Wien ist country=at)? Du musst an jeden Node, der ein addr:postcode hat auch ein addr:country drantun. Nur dann kann der OSM Inspector das richtig erkennen. Ja, das ist suboptimal, aber diese Logik ist halt einfach zu implementieren. 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] Rekordhalter im Relationsfragmentieren
Am 18. Januar 2009 08:46 schrieb Bernd Wurst be...@bwurst.org: Hallo. Am Sonntag, 18. Januar 2009 schrieb Nop: Wo ich grade immer dabei bin, gegen sinnlos zerfitzelte Relationen zu wettern, möchte ich Euch den heutigen Brüller nicht vorenthalten. Ein Nebenprodukt meines Kartenrenderes ist auch ein wenig Relationstatistik. Der Gewinner ist eine Relation vom Typ Route mit einem Way und exakt 7 Metern Länge. :-) Na und? Einer muss anfangen eine Route zu basteln. Ich hab neulich zufällig gesehen, dass von seitlich eine Rad-Route auf den Weg kommt und einige hundert Meter später ging sie wieder rechts ab. Seither gibt es eine Relation für diese Rad-Route, da es diese bisher noch nicht gab. Wenn jetzt jemand diese Relation sucht, findet er was und sieht dass die noch nicht vollständig ist. Gruß, Bernd Erinnert mich an meine Nachtautobus route, besteht aus einem Element und das ist die Endstation. Die Endstation ist nämlich die selbe wie für eine andere Route die ich komplett eingetragen habe, und da es die andere Relation noch nicht gab und ich vor hab sie mal einzutragen, hab ich sie halt (mit allen notwendigen Daten[ref, name, operator, ...]) erstellt. mfg, Kelvan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Bugs schließen
On Tue, 20 Jan 2009, Detlef Reichl wrote: was es kann, kann ich nicht zu 100% sagen, da ich keine Doku gefunden habe. Der Source basiert laut einem Kommentar auf dem GeoImageLayer-Code und sieht auch aus wie eine abgespeckte oder alte Version davon. Als erweiterte Funktion wurde wohl mal versucht eine Sound-Ausgabe einzubauen, allerdings gibt es dazu nur ein winziges auskommentiertes Codefragment. Wenn man das Plug-in wieder zum Laufen bekäme dürfte es aussehen wie der GeoImageLayer, also keinerlei Mehrwert. Na dann. Schließen :-) Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Adress Inspector
On Tue, Jan 20, 2009 at 02:07:58PM +0100, Andreas Labres wrote: Frederik Ramm wrote: Andreas Labres wrote: Frederik Ramm wrote: Wenn Du Hollabrunn ein country=at gibst, wird das aufhören. Wie ist das gemeint? Bei jedem Objekt mit Adresse ein addr:country=at dazu? Genau! Mit Verlaub, aber wieviele Staaten gibt es glaubst Du auf dieser Welt mit plz=2020 und city=Hollabrunn? Noch dazu in diesen LängenBreiten... addr:city wird bei den Postcodeareas nicht berücksichtigt. Es gibt nämlich den Fall, dass ein postcode für mehrere Städte gilt. Ich schaue nur die Kombination aus addr:country und addr:postcode an, die sollte nämlich weltweit eindeutig sein. Irgendwo ist da im Konzept ein eigentlich ist fast alles optional, aber wenn Du nicht alles haarklein angibst, funktioniert der OSMI nicht mismatch... ;) Naja, der OSM Inspector ist halt auch nicht perfekt. Es ist nur ein Tool, um bestimmte Fehler leichter finden und beheben zu können. Klar könnte man den intelligenter machen, und ich würde das vielleicht auch, wenn ich die Zeit dazu habe. Aber andererseits kannst Du auch davon ausgehen, dass die meiste andere Software, die OSM-Daten auswerten wird, auch nicht einem beliebig kompliziertem Algorithmus folgt. Ich bin auch nicht glücklich über die Situation, hab aber auch keine bessere Lösung derzeit. Du musst dem ja auch nicht folgen. Wenn Du es nicht so taggst, dann ists halt nicht richtig im OSM Inspector, aber das ist ja nun auch nicht so schlimm. 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] Französische Katasterdaten
Florian Schweikert kelvan.mailingl...@gmail.com wrote: (Falls es jemanden interessiert, sind vermutlich wenig Franzosen hier) Für die Mapper in Baden und in der Pfalz könnte das aber ebenfalls interessant sein. Die Adresse des WMS-Servers hab ich jedoch leider noch nicht gefunden, dazu ist mein Französisch zu schlecht. Sollte man in dei defaults von josm einbauen. Sven -- Those who do not understand Unix are condemned to reinvent it, poorly (Henry Spencer) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wie kann man eine Relation ermitteln
Moin ! man stelle sich eine Relation vor für einen Weg zum Beispiel der durch ganz Deutschland oder Europa verläuft. Kann ich irgendwo eine Liste aller Relationen, meinetwegen nach Typen gefiltert, bekommen um darin zu suchen ? Wie kann ich sonst wissen ob einer in Bayern oder Italien bereits eine Relation hierzu angelegt und nur in keiner WIKI-Liste eingetragen hat ! Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie kann man eine Relation ermitteln
Hallo, Jan Tappenbeck wrote: Kann ich irgendwo eine Liste aller Relationen, meinetwegen nach Typen gefiltert, bekommen um darin zu suchen ? Wie kann ich sonst wissen ob einer in Bayern oder Italien bereits eine Relation hierzu angelegt und nur in keiner WIKI-Liste eingetragen hat ! Es ist nicht relevant. Es ist nicht Deine Aufgabe, fur alles, was Du mappen willst, erstmal zu schauen, ob es in Italien dafuer schon eine Relation gibt. Das wuerde Dich viel zu sehr vom Mappen abhalten! Entweder gibt es im naeheren Umkreis schon eine Relation, die Du ergaenzen kannst, oder Du machst halt eine eigene, fertig. Wenn sich auf diese Weise 10 Relationen fuer den Jakobsweg bilden, dann stossen die irgendwann irgendwo auch aneinander, und dann kann man sie zusammenlegen oder in einer Superrelation zusammenfassen. Aber bis dahin wuerde ich keinen Gedanken daran verschwenden. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie kann man eine Relation ermitteln
Am Dienstag, den 20.01.2009, 16:16 +0100 schrieb Jan Tappenbeck: Moin ! man stelle sich eine Relation vor für einen Weg zum Beispiel der durch ganz Deutschland oder Europa verläuft. Kann ich irgendwo eine Liste aller Relationen, meinetwegen nach Typen gefiltert, bekommen um darin zu suchen ? Wie kann ich sonst wissen ob einer in Bayern oder Italien bereits eine Relation hierzu angelegt und nur in keiner WIKI-Liste eingetragen hat ! Hallo, Du kannst so etwas über Xapi abrufen http://wiki.openstreetmap.org/wiki/Xapi Dürften aber bei unvorsichtiger Filterwahl sehr viele Daten werden ;-) Ich würde es aber einfach ignorieren und warten bis sich der Kreis von selber schließt. Grüßle, detlef ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rekordhalter im Relationsfragmentieren
Am 19.01.09 schrieb Ekkehart: Ich hab' da schon eine Idee, wie so ein Tag aussehen könnte. Der Frankenweg wäre momentan eingestellt als z.B. render_symbol=roter_balken:hintergrund_rot:FW:text_schwarz Es hatte mal jemand mit marked_trail* angefangen: http://wiki.openstreetmap.org/index.php/Proposed_features/Marked_trail Gruß, Fabian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Franz?sische Katasterdaten
In gmane.comp.gis.openstreetmap.region.de Florian Schweikert kelvan.mailingl...@gmail.com wrote: (Falls es jemanden interessiert, sind vermutlich wenig Franzosen hier) Frankreich liegt hier quasi um die Ecke... Und pfalz eines Tages die Oferfalls fertig ist oder so... ;-) Da geht's doch auch um abmalen, oder? Nicht Import? MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Motorway-Junction - Name
Garry schrieb: Wolfgang W. Wasserburger schrieb: Gruß Jan :-) ich würde den NAME aus den Ways selber weglassen und im Sinne einer Collected Ways-Relation - siehe: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways - den Namen der Ausfahrt dort eintragen. Wenn die Renderer dann irgendwann schlauer geworden sind, könnte man den Namen dann z.B. mittig eintragen. Alles, was nicht auf den Ways ist, sondern auf Nodes macht es den Routern schwerer bzw. wenn die das einbauen, kostet das unnöig Rechenzeit. Daher: besser am way - dieser führt ja tatsächlich von der Autobahn. Das Schild ist ja nur ein Hinweis auf diese Tatsache. Sonst sollten wir ja überhaupt generell keine Straßennamen an die Ways setzen, sondern die Straßenschilder erfassen ;-))) *unterschreib* Ist so wesentlich einfacher im Navi die Position z.B. im Falle eines Unfalls auszugeben. Garry früher oder spter sollten die Navis eh mit Name-Relations klarkommen, wo ist das also die Positionsermittlung einfacher, wenn da (mind.) 4 Wege in sehr kleinem Umkreis den gleichen Namen haben? Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Moin, also bei mir hat das mit dem Routen mit der Karte nicht so dolle geklappt. Mapsource verabschiedet sich jedes Mal mit einer Fehlermeldung. Das Nuevi hat mich einmal erfolgreich drei Strassen weit routen wollen. Als ich noch ein Stueckchen weiter probiert habe, schien das Routing nur noch ueber die Basemap zu laufen. Nun wohne ich hier zwar sehr dicht bei einer Ecke, wo vier Kacheln zusammenstossen, aber ich hatte eigentlich versucht, erstmal immer auf einer Kachel zu bleiben. @Carsten: Setzt du eigentlich bei makemap die draw-priority? Neulich war auf der dev-Liste ein Meldung, dass das jetzt auch unterstuetzt sein sollte. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wander Magazin - GPS Bericht - hat einer gelesen
Hallo, Am Donnerstag, 15. Januar 2009 schrieb Jan Tappenbeck: vielleicht wuerde es fuer die naechste Ausgabe helfen, denen mal was von OSM zu erzaehlen. [...] könnte mir gut vorstellen etwas zusammenzuschreiben - vielleicht findet sich noch einer von den wander/reit/cycle/etc.-karten machern ! Wenn es in drei, vier Wochen reichen würde, könnte ich das Rendern von Karten in dem Stil von http://www.ancalime.de/gutau.html; übernehmen. Der Stil ist noch in Entwicklung, und in anderen Gebieten noch nicht viel getestet, deswegen der vorgeschlagene Zeitraum ... Einen ersten Eindruck könnte ich nach ca. 1/2 bis ganzen Stunde zur Verfügung stellen (hängt natürlich auch von der Gebietsgröße ab). Was bei Zeitschriften auch eine Rolle spielen könnte, ist die Auflösung der Karte. Die Standardstile (Mapnik, Osmarender) sind wegen Schrift- und Icon-Größe eher für Bildschirm-Auflösungen geeignet, deshalb macht es Sinn, etwas neues zu entwickeln ... -- Holger Schoener nume...@ancalime.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Natur- und Landschaftsschutzgebiet-Kart en für OSM
Am 20.01.2009 09:35, Jan Tappenbeck: kann mir einer sagen in wieweit die Definitionen für Natur- und Landschaftsschutzgebiete (siehe auch http://www.luebeck.de/bewohner/umwelt_gesundheit/naturschutz/schutzgebiete/schutzgebiete.html) in OSM übernommen werden können ?? Ich dachte hierbei an die visuelle Übertragung der Begrenzung. Das OSM-Wiki hat eine Suchfunktion: http://wiki.openstreetmap.org/wiki/Proposed_features/Nature_reserve http://wiki.openstreetmap.org/wiki/Proposed_features/conservation Bisher gibt es noch keine Einigung darüber. Es bedarf offenbar eines Tags, das zusätzlich zu natural=* und landuse=*-Tags verwendet werden kann. Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte
Ekkehart ekkeh...@gmx.de writes: Ich persönlich habe ja die illegalen Breschen im Nürnberger Reichswald schätzen gelernt, die die Mountainbiker quer durch die Bäume gebrochen haben. Da konnte ich immer sagen: Da ist schon ein Weg, den kann ich reiten, und mein Pferd liebt solche Hindernisstrecken. Der Flurschaden war eindeutig von 100en von Fahrrädern verursacht, da schimpft auch keiner auf die Reiter. :-) Das ist ja mittlerweile auch irgendwie ausgeschildert und teilweise laufen parallel fuß- und reitwege. Ob die mountainbiker den stein ins rollen gebracht haben, weiß ich nicht. Das muss irgendwie vor meiner zeit passiert sein... Wäre das erste Mal, daß ich sowas erlebe. Normalerweise werden diese Wege nach dem Holzmachen sich selbst überlassen, hier in der Gegend sind welche jetzt schon 2 Jahre unpassierbar, weil einfach einen halben Meter hoch abgesägte Äste auf dem Weg liegen. Da räumt keiner auf. Ich denke, dass der Frankenweg schon gepflegt wird. Richtig unpassierbare stellen für leute mit wanderschuhen sind mir noch nicht untergekommen. Nur wenn man sich permanent irgendwie mit schlammspuren arrangieren muss, geht das etwas auf die kondition. Mir ist auch noch nicht klar, ob mir diese sog. nachhaltige waldwirtschaft besser gefällt, bei der immer nur einzelne bäume geschlagen werden, oder ob es nicht besser ist, bestimmte areale gänzlich einzuschlagen und dann wieder aufzuforsten, Sog. schonungen scheint es kaum noch zu geben... Bei dieser nachhaltigen forstwirtschaft wird permantent mit schwerem gerät im wald herumgefahren und irgendwie ist immer alles in einem sehr unnatürlichen zustand. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bald ganz Österreich auf OpenStreetMap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://futurezone.orf.at/stories/1501860/ - -- Gruß Mario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl2DtsACgkQdRpju1J3VHHqiQCfYTQXdBEQCcsZGOLKAeaaVj9I q3QAn3anlEaS8c3gmSTFQh+SEyNwBE1O =2dYZ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] In Lüneburg wird noch per Hand gemapp t
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.landeszeitung.de/start.phtml?fdat=resultidx=508253 - -- Gruß Mario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl2D1QACgkQdRpju1J3VHFN2wCcDHpSBB0KhF43MBQxhJUilMez /o0AoI/FyX93PAcytvpemBD8AMp8b0QW =t/1x -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wander Magazin - GPS Bericht - hat einer gelesen
Hallo, Am Dienstag, 20. Januar 2009 schrieb Karl Eichwalder: Holger Schöner nume...@ancalime.de writes: Wenn es in drei, vier Wochen reichen würde, könnte ich das Rendern von Karten in dem Stil von http://www.ancalime.de/gutau.html; übernehmen. Die wegeführung ist sehr gut erkennbar. Leider kommt aber die oberflächenbeschaffenheit nicht heraus. Vielleicht ist es doch besser, mit breiten und dafür transparenten linien zu hantieren. Wäre grundsätzlich kein Problem; allerdings wurde bei einer Besprechung mit dem Verschönerungs-Verein von Gutau, der die Erstellung der Karte offiziell übernimmt und drucken will, der Wunsch geäußert, sich erst mal an dem Design einer vorhandenen veralteten Karte zu orientieren. Und dort sieht das so aus ... Außerdem gäbe es beim Rendern mit Transparenten Routen noch eine Kleinigkeit zu beachten: Es liegen hier mehrere Routen übereinander, und die könnte man kaum noch auseinanderhalten, wenn sie transparent übereinander gerendert werden. Und die SQL-Abfragen sind im Moment dadurch noch einigermaßen überschaubar, weil ich mit späteren Layern vorhandene einfach überzeichnen kann. Sollten die Routen transparent gerendert werden, müssten sie deutlich komplexer ausfallen, um Teile auszulassen, wo später noch eine Kombination von mehreren Wegen gerendert wird ... Viele Grüße, -- Holger Schoener nume...@ancalime.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte
Bei mir funktioniert die Adresse nicht. Hat wer nen Link? signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte
André Reichelt schrieb: Bei mir funktioniert die Adresse nicht. Hat wer nen Link? Mist, vergesst das! Alte mail nicht mehr gefunden :( signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Evtl. liegt es auch daran dass in den OSM Tiles die die Quelle der img tiles sind die Grenzen der Kachel fehlen D.h. dort fehlt das bound XML element mit den eigentlichen Kachelgrenzen. Das ist im übrigen auch warum im Mapsource an manchen Stellen die residential Fläche eines Ortes (z.B. in Glauberg 50.314N 9.001E) über einige Straßen gezeichnet wird. mkgmap schneidet die Karte dann nicht direkt an den Kachelgrenzen ab sondern nimmt auch noch die 'überstehenden' Wege und Flächen mit. Diese sind dann aber auch jeweils in den Kacheln also in der ganzen Karte mindestens doppelt vorhanden. Diese doppelten Wege bringen dann vermutlich das Routing durcheinander da es da ja auch keine in beiden Kacheln auf der gleichen Position liegende NOD-Node giebt den in der einen Kachel ist diese ja wahrscheinlich am einen in der anderen am anderen Ende des Wegs. MichaH. Am 20. Januar 2009 10:25 schrieb Bernd Wurst be...@bwurst.org: Naja, aber es ist doch klar, dass das irgendwann gehen muss. Auch Garmin bekommt es hin, dass man über Kachelgrenzen drüber routen kann. Vielleicht müssen dazu irgendwelche IDs aneinander angepasst werden oder whatever. Das bekommen die schon noch irgendwann hin. Moin! Ich habe neulich mal die mkgmap-dev mailingliste durchgelesen, weil mich interessierte, wie viel da im Moment passiert. Hier http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2008q4/000145.html ist ein commit beschrieben, der NOD3-Nodes an den Kachelgrenzen möglich macht, die für das routing über diese hinweg gebraucht werden. Irgendwo anders stand auch, daß dies das einzige sei, was dafür nötig wäre und das routen über Kachelgrenzen jetzt einigermaßen zuverlässig funktioniere... @Carsten: Ich habe versucht, in qlandkartegt alle Kacheln auszuwählen und als gmapsupp.img zu exportieren. Die resultierende Datei ist auch über 500mb groß, aber ich kann z.B. bei Köln ab 7° östlich auf meinem Garmin etrex Vista keine Objekte auswählen und auch nicht routen (westlich 7° innerhalb Kölns funktionert es...). Ich war schon in qlandkartegt skeptisch, weil es nicht so aussah, als seien wirklich alle Kacheln gewählt, aber da die Dateigröße stimmte... MfG, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie kann man eine Relation ermitteln
2009/1/20 Jan Tappenbeck o...@tappenbeck.net Moin ! man stelle sich eine Relation vor für einen Weg zum Beispiel der durch ganz Deutschland oder Europa verläuft. die meisten Wege kommen hier in Rom an. Kann ich irgendwo eine Liste aller Relationen, meinetwegen nach Typen gefiltert, bekommen um darin zu suchen ? Wie kann ich sonst wissen ob einer in Bayern oder Italien bereits eine Relation hierzu angelegt und nur in keiner WIKI-Liste eingetragen hat ! Fuer Bayern kann ich es Dir nicht genau sagen, aber in Italien gibt es die Relation noch nicht, das ist annaehernd sicher. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] In Lüneburg wird noch per Hand gemapp t
Am Dienstag 20 Januar 2009 schrieb DarkAngel: http://www.landeszeitung.de/start.phtml?fdat=resultidx=508253 Lesenswerter Artikel, gratuliere! Aber warum per Hand? Per Pedes bzw. pedaliter, würde ich sagen... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Hallo, Torsten Leistikow schrieb: @Carsten: Setzt du eigentlich bei makemap die draw-priority? Neulich war auf der dev-Liste ein Meldung, dass das jetzt auch unterstuetzt sein sollte. Nein, was bringt das? Macht das das gleiche, wie ich per typ-File die Schichtung bearbeite? -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Hallo, Michael Hufer schrieb: nimmt auch noch die 'überstehenden' Wege und Flächen mit. Diese sind dann aber auch jeweils in den Kacheln also in der ganzen Karte mindestens doppelt vorhanden. Diese doppelten Wege bringen dann vermutlich das Routing Keine Kartenelemente sind doppelt vorhanden. Ein Weg wird genau in eine Kachel gepackt und dann nicht noch einmal behandelt. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortshinweisschild Z 385 (Weiler) Ortsschild
RalfGesellensetter schrieb: (vgl. http://de.wikipedia.org/wiki/Ortstafel) Ortsschilder können aus JOSM heraus nun sehr komfortabel getaggt werden (auch wenn ich noch nicht weiß, woran ersichtlich sein soll, in welche Richtung vom Schild aus der Ort liegt). Die grünen Ortshinweisschilder könnten ggf. als Weiler getaggt werden - aber es ist meist nicht sofort ersichtlich, wo der Schwerpunkt des Weilers liegt - und manchmal handelt es sich wohl auch um eine Ortsvorbeifahrt. Bitte jetzt nicht alles was ein Ortshinweisschild hat als Weiler mappen! Das Schild taucht dort vielleicht überdurschnittlich häufig auf, hat aber ansonsten nichts mit Weiler zu tun. Im Gegensatz zum normalen Ortsschild gibt es hier einfach nur keine besonderen innerörtlichen Verkehrsregeln zu beachten. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsgrad, Erfassen von Spuren etc.
Chris-Hein Lunkhusen schrieb: Getrenntes Mapping bitte nur bei baulich getrennten Spuren. ..sowie bei..._link mit durchgezogenen Linien zur eindeutigen Zuordnung (u.a. als Einbahnstrassen). Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Musik Genre
Da ich keinen tag fand um die Musikrichtung in Lokalen anzugeben habe ich mal ein proposal angefangen: http://wiki.openstreetmap.org/wiki/Proposed_features/Music_genre Würde mich über Verbesserungsvorschläge/Anregungen/konstruktive Kritik etc. freuen. mfg, Kelvan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
Florian Schweikert schrieb: Da ich keinen tag fand um die Musikrichtung in Lokalen anzugeben habe ich mal ein proposal angefangen: http://wiki.openstreetmap.org/wiki/Proposed_features/Music_genre Ich habe in ein paar Nachtclubs bisher das Tag music=* verwendet, music_genre=* ist da natürlich genauer. Guter Vorschlag! Gruß Patrick ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
On Tuesday 20 January 2009 20:14:31 Carsten Schwede wrote: Keine Kartenelemente sind doppelt vorhanden. Ein Weg wird genau in eine Kachel gepackt und dann nicht noch einmal behandelt. Ahh.. dann ist dein Cutter anders als Fredriks C osmcut aus dem osm svn, der einen Weg in alle (max 4) Kacheln einfügt, aus denen er Nodes enthält. Aber das ist m.M. trotzdem das Problem. Wenn ich das Germin Format mit NOD3 Nodes richtig verstehe, müsste dann nämlich auf allen Kreuzungspunkten der Wege, die in andere Kacheln hineinragen, mit den Wegen aus diesen anderen Kachel ein NOD3 Punkt liegen. mkgmap hat aber keine Möglichkeit zu wissen welche Nodes des Wegs (außerhalb der Kachel) eine Kreuzung ist und so dann als ein NOD3 zu setzten wäre und bei welchen nicht. Also m.M. nach bleibt es dabei, für über Kachelgrenzen routingfähige Karten müssen die osm Quelle ein bounds element mit der Kachelgrenze enthalten, so dass mkgmap die Kachel dann auf genau diese Grenze schneiden kann. Allerding muss dann auch jeder Weg der Kachelgrenzen überschneidet in alle OSM-Kacheln, die er trifft rein (wie es Frederiks osmcut macht), damit mkgmap ihn in jeder Kachel an der Grenze schneiden und dort die NOD3-Node(s) setzen kann. Micha H. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
Am 20. Januar 2009 21:12 schrieb Patrick Kolesa patrick.kol...@web.de: Florian Schweikert schrieb: Da ich keinen tag fand um die Musikrichtung in Lokalen anzugeben habe ich mal ein proposal angefangen: http://wiki.openstreetmap.org/wiki/Proposed_features/Music_genre Ich habe in ein paar Nachtclubs bisher das Tag music=* verwendet, music_genre=* ist da natürlich genauer. Guter Vorschlag! Gruß Patrick habe ich auch schon von anderen Leuten gehört das sie schon sachen mit music=* taggen, vielleicht ist music=* besser geeignet. mfg, Kelvan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] In Lüneburg wird noch per Hand gemapp t
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 RalfGesellensetter schrieb: Lesenswerter Artikel, gratuliere! Aber warum per Hand? Per Pedes bzw. pedaliter, würde ich sagen... Ich bezog mich dabei eher auf die Meldungen der letzten Tage aus Frankreich, Österreich, Bayern usw. wo umfangreiche Daten von anderen Stellen zur Verfügung gestellt werden/wurden. - -- Gruß Mario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl2QN8ACgkQdRpju1J3VHFFqwCghdEcYXrTzr7b94eraRnRQJqc yzgAn3Nl6JO+oxKOqwSTxoDvO1eEVJOR =wjP/ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
Es kann ja durchaus sein, dass Nachtclubs keine Musik spielen (wobei ich keinen solchen Club kenne :), dafür wäre dann music=yes/no möglich. Soweit ich weiß gibt es in Spanien ein Café/Club, welches nur freie Musik (z.B, cc) spielt. Da könnte man als Erweiterung auch music_license=* oder music:license=* nehmen. Allgemein finde ich differenzierte Tags besser, denn music allein sagt nicht viel aus. Gruß Patrick ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Plaedoyer fuer Realnamen
So, ich habe nun auch beschlossen meinen Nickname zu verbannen, aber nicht ganz, damit ihr mich weiterhin zuordnen könnt, kommt er in die Klammer ;-) Frohes Schreiben Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
Am 20. Januar 2009 22:36 schrieb Patrick Kolesa patrick.kol...@web.de: Es kann ja durchaus sein, dass Nachtclubs keine Musik spielen (wobei ich keinen solchen Club kenne :), dafür wäre dann music=yes/no möglich. Soweit ich weiß gibt es in Spanien ein Café/Club, welches nur freie Musik (z.B, cc) spielt. Da könnte man als Erweiterung auch music_license=* oder music:license=* nehmen. Allgemein finde ich differenzierte Tags besser, denn music allein sagt nicht viel aus. Gruß Patrick Auch wieder war, das mt license kann man auch später mal hinzufügen, ist (noch) nicht so verbreitet freie Musik zuspielen. mfg, Kelvan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Adress Inspector
Jochen Topf schrieb: On Tue, Jan 20, 2009 at 11:56:11AM +0100, Andreas Labres wrote: Frederik Ramm wrote: Wenn Du Hollabrunn ein country=at gibst, wird das aufhören. Wie ist das gemeint? Bei jedem Objekt mit Adresse ein addr:country=at dazu? Oder kann man global sagen Hollabrunn ist country=at (bzw. Wien ist country=at)? Du musst an jeden Node, der ein addr:postcode hat auch ein addr:country drantun. Nur dann kann der OSM Inspector das richtig erkennen. Ja, das ist suboptimal, aber diese Logik ist halt einfach zu implementieren. Jochen Ich sehe da keine Probleme. Man muss es ja nicht immer jeder Adresse sofort hinzufügen. Ich z.B. trage sehr oft den Ort und die Landeskennung hinterher in einem Rutsch ein. Im Regelfall habe ich nur die Daten eines kleines Ausschnittes in Bearbeitung, dann wird nach addr gesucht und die fehlende Werte ergänzt. Nur bei Ortsgrenzen muss man halt auspassen, nicht den Nachbarort zu treffen ;-) Das ist gerade hier im Ruhrgebiet nicht ganz so einfach. Wir haben sogar Anwohnerstraßen an denen sich die Ortgrenze in der Mitte der Straße befindet. Da muss es dann halt einzeln ausgewählt werden. Ropino ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige De-Karte
Hallo, Michael Hufer wrote: Ahh.. dann ist dein Cutter anders als Fredriks C osmcut aus dem osm svn, der einen Weg in alle (max 4) Kacheln einfügt, aus denen er Nodes enthält. Das osmcut war mehr so eine Schnellschuss-Reimplementierung des originalen osmcut von Carsten, das es irgendwo als jar-File gab, ich hab das dann einfach nachprogrammiert. Wenn ich vom aktuellen osmcut ein jar oder eine Algorithmusbeschreibung bekomme, kann ich das auch nachbauen, waer kein Problem, aber mangels akuten Bedarfs hab ich mich da nie drum gekuemmert. Carsten scheint lt. Userpage cutTheOsmPlanet.jar von Heiko einzusetzen (Das Programm wird später noch veröffentlicht.). 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-de
Re: [Talk-de] taggen für den Checker - Gehts noch?
Frederik Ramm schrieb: (Von noexit=yes halte ich ueberigens gar nichts. Ich plaediere dafuer, dass wir ein allgemeines Tag benutzen, mit dem man Validatoren aller Art Metainformationen zukommen lassen kann nach dem Motto lieber so-und-so-check, ignoriere bitte diesen Sachverhalt hier, der ist schon in Ordnung so. noexit=yes ist ganz klar ein Tagging fuer den Checker, denn fuer alle anderen Anwendungsfaelle reicht ja der Sachverhalt, dass die Strassen nicht verbunden sind; nur der Checker ist so vorlaut, anzunehmen, dass dies vielleicht ein Fehler sein koennte. Und Tagging fuer den Checker ist nichts schlechtes, sollte aber ganz klar als solches erkennbar sein, also z.B. validator:ignore=street_ends_near_other_street oder so.) In der Literatur schreibt man [sic] um zu kennzeichnen, dass man eine Schreibweise oder eine ungewöhnliche Tatsache genau so und nicht anders meint. In OSM könnten wir sic=yes schreiben. Das ist international, leicht zu merken und schnell zu tippen. Es passt auch für andere unübliche Dinge wie eine Bootstankstelle für die Frederik das Tag validator:ignore=fuel_station_on_water_and_not_near_street einbauen müsste. Grundsätzlich kann man besser warten bis ein Validator meckert und dann per Mausklick bestätigen, dass die Daten an dieser Stelle korrekt sind. Das kann der Validator dann zunächst als Liste speichern und später für eine Verbesserung der Regeln nutzen. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ost-Seegrenze; war: Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)
Hallo, Frederik Ramm schrieb am 2009-01-17: Ich habe zumindest den Eindruck, dass einige der aktuell eingetragen 12-Seemeilen-Linien näher an Dänemark als an Deutschland liegen. Oder täuscht das? Der Einwand hat mir keine Ruhe gelassen. Und leider liegt Frederik völlig richtig: Teilweise liegt die Grenze viel zu weit nördlich. Die Grenze wurde nachträglich erheblich verändert (benannte Punkte 1-5, 12-21, 23, 30 geändert, 25 und 29 gelöscht). Übrigens zeigen offizielle Karten (http://www.bsh.de/de/Meeresnutzung/Wirtschaft/CONTIS-Informationssystem/index.jsp), dass zwar die ausschließlichen Wirtschaftszonen von DE und DK in der Ostsee gemeinsame Grenzen haben, aber größtenteils die jeweiligen Küstenmeer (12sm-Zone) NICHT. Es müsste für DK eine separate Grenze gezogen werden. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte (im neuen Gewand)
Am 20.01.2009 19:17, André Reichelt: Bei mir funktioniert die Adresse nicht. Hat wer nen Link? Andere Variante: http://osmc.broadbox.de/ Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Adress Inspector
Hi, Ropino wrote: Ich sehe da keine Probleme. Man muss es ja nicht immer jeder Adresse sofort hinzufügen. Ich z.B. trage sehr oft den Ort und die Landeskennung hinterher in einem Rutsch ein. Im Regelfall habe ich nur die Daten eines kleines Ausschnittes in Bearbeitung, dann wird nach addr gesucht und die fehlende Werte ergänzt. Funktioniert die automatische Vorbelegung des Presets im JOSM bei Dir nicht? 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-de
[Talk-de] Neue Mailingliste Franken
Hi! Es gibt jetzt eine neue Mailingliste für Franken. Ein Schwerpunkt wird wahrscheinlich der Raum Nürnberg/Fürth/Erlangen bilden, aber es sind auch Leute aus anderen fränkischen Gegenden gern gesehen. Anmelden könnt ihr euch unter: http://lists.openstreetmap.de/cgi-bin/mailman/listinfo/franken Mein Dank geht an Sven Anders für die Einrichtung der Liste! Gruß, ULFL P.S: Das nächste NFE-Treffen in Fürth findet am Do. 29.01. statt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ost-Seegrenze; war: Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)
Frederik Ramm schrieb am 2009-01-17: Ich habe zumindest den Eindruck, dass einige der aktuell eingetragen 12-Seemeilen-Linien näher an Dänemark als an Deutschland liegen. Oder täuscht das? Der Einwand hat mir keine Ruhe gelassen. Und leider liegt Frederik völlig richtig: Teilweise liegt die Grenze viel zu weit nördlich. Die Grenze wurde nachträglich erheblich verändert (benannte Punkte 1-5, 12-21, 23, 30 geändert, 25 und 29 gelöscht). Ah vielen Dank fürs nachgucken. Da die Ostseegrenze immer schon die source-Tags hatte habe ich die nicht angefasst. Hast Du das wieder korrigiert? Gruß, Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)
Hallo, vielen Dank für die ganzen Antworten und die Verbesserungsvorschläge. Nur mal vorweg: Ich habe seit vier Tagen die Daten nicht angeguckt, kann also sein, dass da inzwischen schon jemand was geändert hat und damit Teile von dem was ich schreibe hinfällig werden. Als Klarstellungen bzw. Änderungen: 1) Es gibt pro Land und Kreis zwei Relationen, eine für die Landmasse und eine für den 'korrekten' Grenzverlauf. Dies gilt natürlich nur wenn sich die beiden Fälle unterscheiden. 2) Ich loesche die INFAS-'Küstenlinie' nicht sondern tagge sie als obsolet 3) Ich füge boundary=administrative bzw. land_area=administrative ein wo es fehlt 4) Meine Anmerkung zu der Relation Germany (Landmass) ist auch halbwegs hinfällig, da das ein Mißverständnis war (jmd. hat die fälschlicherweise umbenannt) - übrigens ein weiterer Grund warum solche, sich wahrscheinlich selten bis nie ändernden Relationen, im Wiki dokumentiert werden sollten - Die Wikiseiten http://wiki.openstreetmap.org/wiki/DE:Grenze und http://wiki.openstreetmap.org/wiki/Schleswig-Holstein mit den neuen Relationen aktualisieren. Ich verstehe nicht wofür wir die Wikiseite mit irgendwelchen IDs brauchen, aber wenn du sie haben möchtest bitte. Ich gucke einmal die Woche all die Grenzrelationen von SH durch (mit dem großartigen Relation Analyzer) und dabei klicke ich mich einfach durch die Wiki-Seiten. Klar kann man jedes mal irgendwelche DB-Abfragen machen aber so eine Relation sollte doch eigentlich stabil bleiben auf Jahre und ich sehe nicht warum man das dann nicht dokumentieren sollte. Außerdem kann ich darüber immer nur die XML-Datei laden, die ich brauche und in JOSM bearbeiten. Aus genau dem Grund kann ich auch nicht verstehen warum die ganzen alten Relationen geloescht wurden und durch neue (die tlw. identisch sind) ersetzt wurden. Aber egal ich werde einfach die Wiki-Seiten aktualisieren, alleine auch schon um eine Übersicht zu bekommen, die dringend noetig ist wie wir an der Germany (Landmass) Sache gesehen haben. - Es gab einen Vorschlag dafür wie die Landmasserelationen getaggt werden koennten. Gab es da eine Einigung? Jochen hatte auf talk-de einen Vorschlag, ich habe ihn aber auch nicht mehr in meiner Mailbox. Außerdem ist der nicht international diskutiert worden. Vielen Dank Jochen für den Link. Ich hatte das nicht mehr gefunden. Ich werde das so taggen wie von Dir vorgeschlagen - Ist noch irgendwer in SH aktiv was die Grenzen angeht? Ich würde mich in den nächsten Tagen dort austoben und ähnliches machen, wie du. Wenn ich aber dabei mehr störe würde ich mich auch zurückhalten, hab sowieso genug Baustellen. Ich würde das auf jeden Fall machen habe aber keinen festen Zeitplan. Ich schaue einfach was vorhanden ist und was nicht. Wenn ich sehe, dass irgendwo schon alles so gemacht wurde wie ich es mir wünsche (siehe meine Ausführungen dazu) dann lasse ich meine Finger davon :) Danke Deine Mail war gut, vergesse immer wieder zu komunizieren, und das gibt dann eher mehr Probleme. Vielen Dank. Ich gebe mir Mühe. Es ist manchmal trotzdem nicht einfach. Oder anders formuliert: Es hat auch Vorteile einfach zu 'machen' ohne vorher groß zu diskutieren ;-) Gruß, Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Objekte gegen Änderungen schützen
Hallo, es gibt immer mal wieder die Anforderung, dass Objekte gegen Änderungen geschützt werden sollen. Die Forderung, oder der Wunsch, kommt aus verschiedensten Richtungen; manche hätten gern am liebsten ihre ganze Stadt geschützt, damit man nur noch mit Zustimmung von drei alteingesessenen Mappern etwas ändern darf. Andere möchten einzelne Objekte schützen, zum Beispiel einen importierten Datenpunkt, an dessen Koordinaten eben einfach nichts zu ändern ist, weil er per definitionem 100% richtig ist (ein Stützpunkt eines in internationalen Übereinkünften festgelegten Grenzverlaufs z.B.). Grundsätzlich halte ich es für sehr unwahrscheinlich und auch gar nicht wünschenswert, dass wir in naher Zukunft irgendeine echte Schutz-/Sperrmöglichkeit in die Datenbank einbauen (ausser vielleicht für Admins, um bei Edit Wars einzugreifen o.ä.). Ich könnte mir aber gut vorstellen, dass man Objekte dadurch schützt, dass man beim Auslesen der Daten gewisse automatisierte Prüfungen macht. Beispielsweise könnte man einen Checksummen-Algorithmus definieren: Nimm lat und lon, schreibe sie hintereinander, nimm die ersten 4 Bytes der MD5-Summe. Dann würde man dem Node ein checksum=0xdeadbeef geben, passend zu seinen Koordinaten. Programme, die Daten auslesen, könnten bei solchen Nodes die Checksumme prüfen, und wenn sie nicht zu den Koordinaten passt, den Node ignorieren (oder den Benutzer irgendwie warnen). Das wäre ein effektiver Schutz gegen des *versehentliche* Verschieben eines Nodes. (Jemand könnte argumentieren, dass man genauso einfach protected=yes schreiben könnte und der Editor den Benutzer dann warnen soll. Aber das erforder, dass alle Editoren mitziehen, während es der o.g. Lösung völlig egal ist, ob ein Editor mit dem checksum-Tag etwas anfangen kann oder nicht!) Der Checksum-Algorithmus könnte auch komplizierter werden, indem man zwei Tags nimmt (checksum:tags=highway,name,ref und checksum:value=0xdeadbeef) und so auch den Wert verschiedener Tags mit in die Pruefsumme einbeziehen kann. Eventuell noch checksum:reason dazu, um zu erklaeren, warum diese Daten speziell geschuetzt sind. Wenn man weiter geht und sich auch gegen *absichtliche* Datenänderungen schützen will, gäbe es einmal den trust-Weg, dazu hat grad jemand was auf talk geschrieben: Man hat eine Liste von Benutzern, denen man vertraut, und bei bestimmten Objekten - z.B. der genauen Lage von Lufträumen oder Seezeichen - verlässt man sich ausschliesslich auf diese Leute, d.h. sobald ein Objekt von jemand anderem zuletzt verändert wurde, fällt es raus. Die Gefahr hierbei ist, dass nicht jeder, der einen kleine Änderung am Seezeichen vornimmt und daher als letzter Bearbeiter verzeichnet ist, eine Gewähr für die Richtigkeit er anderen, von ihm nicht veränderten, Angaben übernehmen will. Eine ähnliche Alternative dazu wäre eine Art Qualitäts-Gremium, das jede Änderung abnicken muss. Man kann in OSM ja auch eine unveränderte Version eines Objekts neu hochladen. Wenn ich also mit 10 Leuten eine Seezeichen-Qualitätskontrollgruppe gründe, könnten wir zusammen einen OSM-Account anmelden und den alle benutzen, um alle Seezeichen zu prüfen und mit unserem Accountnamen abzustempeln. Alle könnten weiterarbeiten wie immer, und wenn jemand genau unsere abgesegnete Seezeichenkarte will, wird er beim Download halt alles rauswerfen, was nicht von unserem Account kommt. Wir würden zugleich ein Tool a la OSM-Inspector oder OSM Mapper einsetzen, um schnell zu sehen, wenn irgendjemand eines von unseren Objekten ändert, um diese Änderung dann auch prüfen und abstempeln zu können. Statt des Vertrauens in Accountnamen könnte man auch Vertrauen in irgendwelche Krypto-Tokens setzen, also sowas ähnliches wie mein Checksummen-Beispiel, nur halt basierend auf public key-Kryptographie. Ich sehe allerdings nicht wirklich einen Anwendungsfall dafür, ausser man würde der Benutzerverwaltung auf dem zentralen Server misstrauen. Die OSMXapi hat übrigens ein interessantes Feature, das in diese Richtung geht (siehe http://wiki.openstreetmap.org/index.php/Osmxapi#RSS_Feed). Hier wird ein bestimmtes Tag ausgewertet, mit dem Benutzer ein Objekt auf ihre Watchlist setzen können, und selbst wenn andere Benutzer dieses Tag entfernen, wird OSMXapi diese Änderung ignorieren. Es gibt also die Möglichkeit, bei völliger Freiheit in der zentralen OSM-Datenbank, trotzdem einen gefilterten Mirror zu betreiben, der Änderungen nur dann übernimmt, wenn sie nach irgendwelchen programmierten Regeln zulässig sind. 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-de
[Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo, Vorab: Dieses Thema betrifft natürlich nicht nur die deutsche Community, jedoch wollte ich es erstmal hier ansprechen. Mir ist in letzter Zeit immer wieder aufgefallen, dass es in OSM keine Möglichkeit gibt, richtige Entscheidungen zu treffen. Die Admins und Programmierer treffen natürlich Entscheidungen bezüglich der Websites, der API (wie läuft das eigentlich?) oder der Anwendungen rund um OSM. Aber inbesondere das Mapping, die Tags, also letztlich der Bereich der OSM am Laufen hält, ist kaum reglementiert. Im Moment scheint es mir eher so, dass es für alles einen eher schwammigen Konsens gibt, aber weniger klare (dokumentierte) Regeln. Was allerdings genau dieser Konsens ist und wieviele sich daran halten, ist nicht bekannt. Im Wiki ist zwar einiges dokumentiert, aber wirklich 'offiziell anerkannt' sind die Seiten dort auch nicht (nicht zuletzt weil jeder reinschreiben kann was er will). Es mappt also jeder eher nach Gefühl, wie es ihm gerade am logischsten erscheint. Bitte nicht falsch verstehen: Es ist nichts an der 'Offenheit' von OSM auszusetzen. Jeder kann sich gerne neue Tags ausdenken und anwenden oder Dinge mappen die sonst keiner mappt. Aber es kann ja irgendwie nicht sein, dass man bei Tags die sehr weit verbreitet sind, nicht genau weiß was sie bedeuten. Das Wiki-Prinzip mag ja funktionieren, aber auch dafür braucht es klare Regeln. Denn es kann niemand etwas korrigieren, von dem er nicht weiß wie man es 'richtig' macht. Wiegesagt: Es geht nicht darum nur irgendwelche 'offiziellen' Tags zuzulassen, sondern die in Benutzung befindlichen Tags so zu definieren und zu dokumentieren, dass man sie nachträglich auch eindeutig automatisiert interpretieren kann. Man kann auch nicht davon ausgehen, dass sich 'das Bessere durchsetzt'. Das funktioniert sicherlich bei unterschiedlichen Tags (also sowas wie path vs. footway/cycleway), deren Häufigkeit man wunderbar in Tagwatch ablesen kann. Aber die Bedeutung geht daraus nunmal nicht hervor. Man kann also nicht daraus ablesen, wie oft z.B. ein highway=cycleway mit der Bedeutung 'benutzungspflichtiger Radweg' und wie oft mit der Bedeutung 'irgendein Weg auf der hauptsächlich zum Radfahren benutzt wird' vorkommt. Ein weiteres Problem, das aber auch mit Entscheidungen zu tun hat, ist die Frage nach 'offiziellen' oder 'empfohlenen' Tags, also letztlich den Map Features. Auch hier gibt es Unklarheiten, wie diese ausgewählt werden oder wer letztlich zu entscheiden hat was in die Map Features kommt. Laut dem Wiki[1] dient der Proposal Prozess hauptsächlich dazu, Tags für die Map Features auszuarbeiten. Also quasi 'offizielle' (oder empfohlene) Tags. Das ist alles schön und gut, aber es gibt folgende Probleme: - Es machen zuwenig bei Abstimmungen mit um wenigstens etwas repräsentativ zu sein. - Während von einem Teil der Leute die Integration erfolgreicher Proposals in die Map Features erwartet wird (also so wie es auch im Wiki beschrieben ist), sehen andere in dem Proposal Prozess nichts anderes als eine Möglichkeit über Ideen zu diskutieren, wobei ein positives Votingergebnis nicht automatisch die Aufnahme in die Map Features bedeutet. Dabei kommt es natürlich zu Spannungen, wenn jemand der Meinung ist, es gehöre nicht zu den Map Features. - Es ist nicht klar definiert, wann ein Proposal angenommen ist (und was das bedeutet, siehe vorheriger Punkt). - Da der Proposal Prozess nicht klar definiert oder irgendwie allgemein akzeptiert ist und es niemand gibt der mal ein Machtwort spricht, können solche Streitereien wie bei smoothness schnell in einem Edit-War oder Ähnlichem enden (das bringt niemandem etwas). Mein Vorschlag: Den Proposal Prozess hauptsächlich zur Ausarbeitung und Diskussion neuer Vorschläge verwenden. Das Voting sollte dabei nur ein Stimmungsbild der Interessierten darstellen, um festzustellen ob das Proposal in der definierten Form prinzipiell ankommt. Eine erfolgreiche Abstimmung sollte die Definition des Proposals festlegen, es sollte also danach nicht mehr verändert werden. Die Aufnahme in die Map Features sollte zwar vom Voting-Ausgang abhängig sein, aber auch davon ob der Vorschlag tatsächlich in Benutzung ist. Das bedeutet eben nicht unbedingt sofort nach dem Voting, sondern erst wenn der Tag auch in der Praxis erprobt ist. Ob die Aufnahme dann wieder durch ein Voting oder ein Gremium oder sowas entschieden wird, müsste man noch überlegen. Gleichzeitig müssten Accepted Proposals auch für 'normale Mapper' leichter zugänglich sein. Also als 'gleichwertige' Tags gelten, die bloss aufgrund von geringer Verbreitung oder Wichtigkeit nicht zu den 'Haupttags' (Map Features) gehören. Beide, Map Features und Accepted Proposals sollten aber gleichermaßen eindeutig definiert sein, damit sie anständig benutzbar sind. Bleibt noch die Frage wie schon existierende Features verändert werden können. Angenommen man wollte einen Tag genauer oder etwas anders definieren (nachträglich
Re: [Talk-de] Ost-Seegrenze; war: Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)
Lars Francke schrieb: Ah vielen Dank fürs nachgucken. Da die Ostseegrenze immer schon die source-Tags hatte habe ich die nicht angefasst. Hast Du das wieder korrigiert? Nein. Ich bin mir nicht klar, was das günstigste Vorgehen ist. Man könnte die Revert-Funktion von Potlatch versuchen. Ich habe ansonsten die Original-Koordinaten für die geänderten Punkte als Punkte mit JOSM gespeichert. Übrigens wurden auch noch Punkte eingefügt. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ost-Seegrenze; war: Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)
Norbert Kück schrieb: Lars Francke schrieb: Ah vielen Dank fürs nachgucken. Da die Ostseegrenze immer schon die source-Tags hatte habe ich die nicht angefasst. Hast Du das wieder korrigiert? Nein. Ich bin mir nicht klar, was das günstigste Vorgehen ist. Man könnte die Revert-Funktion von Potlatch versuchen. Ich habe ansonsten die Original-Koordinaten für die geänderten Punkte als Punkte mit JOSM gespeichert. Übrigens wurden auch noch Punkte eingefügt. Ja die eingefügten Punkte sind eine Konsession an die Renderer. Ohne diese Punkte würde die Grenze sehr zerstückelt aussehen, da die Renderer mindestens eine Node pro Tile benötigen um eine Linie zeichnen zu können. Leider können die eben 'nur durchlaufende' Linien ohne Node nicht erkennen. Manchmal muß man halt doch für den Renderer taggen!? You can't have it all! Gruss mikes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Am Mittwoch, den 21.01.2009, 00:13 +0100 schrieb Frederik Ramm: [sehr ausführlich] Hallo Frederik, ich schließe mich dir an, das keine Nutzergruppen mit besonderen Rechten implementiert werden sollten. Was dabei raus kommt sieht man bei WikiPedia. Dort muß derweil auch die kleinste Änderung an den meisten (alle?) Artikeln von den Admins abgenickt werden. Das tötet die Motivation vieler Leute. Auf der anderen Seite fände ich ein Werkzeug zur Überwachung von Bereichen oder Objekten sehr hilfreich. Auch ich habe ein paar Objekt, die mir mit der Erstellung recht viel Zeit gekostet haben und die ich nicht gern verunstaltet sähe. Um Verunstaltungen rückgängig machen zu können sollte es simple Werkzeuge geben, mit denen man auf eine beliebigen Versionsstand für eine Objekt oder einen Bereich zurückgehen kann. Dieses Werkzeug sollten für den normalen Benutzer auf eine bestimmte Anzahl von Versionsständen begrenzt sein. In diesen Bereich hätte ich kein Problem damit, wenn es Benutzer gäbe, die - aufgrund dessen was sie zum Projekt beigetragen haben - erweiterte Rechte hätten, um z.B. auch auf ältere Versionen zurückspielen zu können. Grüßle, detlef ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am 21. Januar 2009 00:17 schrieb Sebastian Hohmann m...@s-hohmann.de: Hallo, Mir ist in letzter Zeit immer wieder aufgefallen, dass es in OSM keine Möglichkeit gibt, richtige Entscheidungen zu treffen. ... Aber inbesondere das Mapping, die Tags, also letztlich der Bereich der OSM am Laufen hält, ist kaum reglementiert. Du hast Dir viel Mühe gegeben, mal wieder einen Vorstoß in Richtung ordentlich demokratisch zu wagen, das wurde schon des öfteren von verschiedenen Leuten angeregt, wird aber aller Voraussicht nach auch in Zukunft nicht kommen, und ich muss sagen, nachdem ich anfangs noch etwas skeptisch war, freue ich mich mittlerweile, dass das aktuelle System erstaunlich gut funktioniert. Im Moment scheint es mir eher so, dass es für alles einen eher schwammigen Konsens gibt, aber weniger klare (dokumentierte) Regeln. Was allerdings genau dieser Konsens ist und wieviele sich daran halten, ist nicht bekannt. die allermeisten halten sich dran, was der Konsens ist, siehst Du, wenn Du die Karten mit der Realität abgleichst, also wie bisher gemappt wurde (und da siehst Du auch, dass es an manchen Stellen noch keinen Konsens gibt (s. straßenbegleitende Radwege, Spuren, etc.)) Im Wiki ist zwar einiges dokumentiert, aber wirklich 'offiziell anerkannt' sind die Seiten dort auch nicht (nicht zuletzt weil jeder reinschreiben kann was er will). das stimmt nicht ganz. Die Community wacht darüber, was dort auf längere Sicht steht. Aber es kann ja irgendwie nicht sein, dass man bei Tags die sehr weit verbreitet sind, nicht genau weiß was sie bedeuten. das ist in der Regel auch nicht so, tags, die weit verbreitet sind, sind auch im Wiki dokumentiert. Falls Fragen offen bleiben: am besten die anderen fragen (hier in der Liste). Das Wiki-Prinzip mag ja funktionieren, aber auch dafür braucht es klare Regeln. Denn es kann niemand etwas korrigieren, von dem er nicht weiß wie man es 'richtig' macht. naja, das kannst Du Dir vorstellen wie Kinder erziehen: da weiss auch niemand, wie man es richtig macht, im Grunde macht man es so gut man kann und meist schöpft man aus der familiären Erfahrung (d.h. so, wie man selbst erzogen wurde oder denkt, dass man hätte erzogen werden sollen ;-) ). , wie oft z.B. ein highway=cycleway mit der Bedeutung 'benutzungspflichtiger Radweg' und wie oft mit der Bedeutung 'irgendein Weg auf der hauptsächlich zum Radfahren benutzt wird' vorkommt. wenn ich mit dem Fahrrad unterwegs bin, und das bin ich fast ausschließlich, dann ist das für mich praktisch egal, hauptsache ich kann mit dem Fahrrad dort fahren (gut, fairerweise muss ich dazusagen, dass Verkehrsregeln an meinem Wohnort deutlich freier ausgelegt werden als in Deutschland, und man sich mit dem Fahrrad überhaupt nicht dran halten muss). Das ist alles schön und gut, aber es gibt folgende Probleme: - Es machen zuwenig bei Abstimmungen mit um wenigstens etwas repräsentativ zu sein. tja, ich mache dort mit, aber eigentlich zeigt das ja, dass Dein Ansatz der formalen Demokratie aufgrund von Politikverdrossenheit zum Scheitern verurteilt ist. Die meisten der 70.000 Freizeitmapper haben offensichtlich keine Lust, das Gros ihrer Mapping-Zeit mit Regelverwaltung zu verbringen. - Es ist nicht klar definiert, wann ein Proposal angenommen ist (und was das bedeutet, siehe vorheriger Punkt). soweit ich weiss, gibt es da Regeln: mehr als 15 Beteiligungen (oder warens ja-stimmen) und mehr ja als nein-Stimmen. Gleichzeitig müssten Accepted Proposals auch für 'normale Mapper' leichter zugänglich sein. Also als 'gleichwertige' Tags gelten, die bloss aufgrund von geringer Verbreitung oder Wichtigkeit nicht zu den 'Haupttags' (Map Features) gehören. Beide, Map Features und Accepted Proposals sollten aber gleichermaßen eindeutig definiert sein, damit sie anständig benutzbar sind. das wäre m.E. noch unübersichtlicher, wenn man die features sozusagen noch auf 2 Seiten verteilt: wichtige und unwichtige. Lieber eine features-Liste. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Geofabrik Tools kaputt?
Was ist mit den Tools von Geofabrik los? Unter http://tools.geofabrik.de bekomme ich zwar die Toolsseiten mit dem unterlegten Layern angezeigt, aber statt der Tool-Layer sehe ich eine Masse Text, die nach Fehlermeldungen für Java aussehen. Leider läßt sich den Text nicht mit dem Cutpaste fangen. Benutze Firefox 3.0.5 unter XP mit Java 6 Update 7. (Cache schon geleert.) Gruss mikes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Am 21. Januar 2009 00:13 schrieb Frederik Ramm frede...@remote.org: Hallo, es gibt immer mal wieder die Anforderung, dass Objekte gegen Änderungen geschützt werden sollen. ich sehe das im Großen und Ganzen kritisch: wer sollte z.B. unentgeltlich alle Seezeichen überprüfen, vor allem, da sich diese ständig ändern (in den Daten und vermutlich auch in Echt), und dann evtl. sogar noch dafür haften? Auch sehe ich unsere Daten noch nicht vollständig genug. Dennoch habe ich mich in letzter Zeit über bestimmte member geärgert, die offensichtlich bereits bestehende vereinzelte Straßen löschen, um dann auf einer weissen Fläche vermeintlich schneller alles nochmal eingeben zu können (zumindest war das meine Interpretation, weil ich bei Straßen, die ich eingegeben hatte, nicht mehr in der history auftauchte). Auch bestimmte Tools halte ich für schädlich (simplify way). M.E. sollte man da einen Schutz einbauen, dass man damit nur *ways* bearbeiten kann, deren *nodes* man *selbst* hochgeladen hat, bzw. vor dem Hochladen (bzw. bei gemischten ways sollten von dem Tool nur die Nodes berücksichtigt werden, die man selbst eingegeben hat). Die anderen vorgeschlagenen Verfahren zur Qualitätssicherung halte ich dagegen eher für kontraproduktiv, auch wenn es im ersten Moment verlockend scheint. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Martin Koppenhoefer schrieb: Am 21. Januar 2009 00:17 schrieb Sebastian Hohmann m...@s-hohmann.de: Hallo, Mir ist in letzter Zeit immer wieder aufgefallen, dass es in OSM keine Möglichkeit gibt, richtige Entscheidungen zu treffen. ... Aber inbesondere das Mapping, die Tags, also letztlich der Bereich der OSM am Laufen hält, ist kaum reglementiert. Du hast Dir viel Mühe gegeben, mal wieder einen Vorstoß in Richtung ordentlich demokratisch zu wagen, das wurde schon des öfteren von verschiedenen Leuten angeregt, wird aber aller Voraussicht nach auch in Zukunft nicht kommen, und ich muss sagen, nachdem ich anfangs noch etwas skeptisch war, freue ich mich mittlerweile, dass das aktuelle System erstaunlich gut funktioniert. Den Eindruck dass es ausnahmslos funktioniert habe ich nicht, lasse mich aber gerne vom Gegenteil überzeugen. Im Moment scheint es mir eher so, dass es für alles einen eher schwammigen Konsens gibt, aber weniger klare (dokumentierte) Regeln. Was allerdings genau dieser Konsens ist und wieviele sich daran halten, ist nicht bekannt. die allermeisten halten sich dran, was der Konsens ist, siehst Du, wenn Du die Karten mit der Realität abgleichst, also wie bisher gemappt wurde (und da siehst Du auch, dass es an manchen Stellen noch keinen Konsens gibt (s. straßenbegleitende Radwege, Spuren, etc.)) Also ich sehe in der Interpretation von Tags teils erhebliche Unterschiede. Aber vielleicht gehen da auch unsere Erwartungen an die Genauigkeit der Daten auseinander. Im Wiki ist zwar einiges dokumentiert, aber wirklich 'offiziell anerkannt' sind die Seiten dort auch nicht (nicht zuletzt weil jeder reinschreiben kann was er will). das stimmt nicht ganz. Die Community wacht darüber, was dort auf längere Sicht steht. Auch den Eindruck habe ich nicht unbedingt. Auf vielen Wiki-Seiten stehen z.B. widersprüchliche Dinge (seit Jahren!), die eigentlich ausgeräumt sein müssten, wenn die Community tatsächlich so gut darüber wacht. Ebenso stehen (oder standen) dort Dinge, die z.B. hier in der Liste als falsch angesehen wurden über lange Zeit. Aber es kann ja irgendwie nicht sein, dass man bei Tags die sehr weit verbreitet sind, nicht genau weiß was sie bedeuten. das ist in der Regel auch nicht so, tags, die weit verbreitet sind, sind auch im Wiki dokumentiert. Falls Fragen offen bleiben: am besten die anderen fragen (hier in der Liste). Dann frage ich dich hiermit, was genau das über 10.000 mal benutzte access=destination bedeutet und welcher Deutschen Zugangsbeschränkung das entsprechen soll (falls du aus Deutschland kommst). Vielleicht bin ich hier ja auch zu kleinlich, aber als ich vor einiger Zeit mal hier auf der Liste nach sowas gefragt habe, kamen schätzungsweise von vielleicht 5 Leuten 4 verschiedene Antworten. Wenn man dabei die gleichen Antworten bekommen würden, wäre es ja kein Problem. Das Witzige dabei ist, dass access=* eigentlich für die 'allgemeine Zugangsbeschränkung' steht (also vermutlich für alle Verkehrsteilnehmer, vermutlich weil das im Wiki nicht klar steht). access=destination für alle Verkehrsteilnehmer (also inklusive Fußgänger, Radfahrer und Pferde) gibt es in Deutschland meines Wissens nach aber garnicht. Zudem noch zwischen Zeichen 250 (für alle Fahrzeuge) und Zeichen 260 (für alle Motorfahrzeuge, also Fahrräder erlaubt) unterschieden werden müsste. Gerade weil auch Fahrradrouting und andere 'exotischere' Dinge wie Pferderouting eigentlich mit OSM möglich sein sollten, müsste sowas eigentlich etwas genauer eingetragen werden. Das Wiki-Prinzip mag ja funktionieren, aber auch dafür braucht es klare Regeln. Denn es kann niemand etwas korrigieren, von dem er nicht weiß wie man es 'richtig' macht. naja, das kannst Du Dir vorstellen wie Kinder erziehen: da weiss auch niemand, wie man es richtig macht, im Grunde macht man es so gut man kann und meist schöpft man aus der familiären Erfahrung (d.h. so, wie man selbst erzogen wurde oder denkt, dass man hätte erzogen werden sollen ;-) ). Hmm.. Kinder sind aber auch keine Daten, die mit klar definierten Algorithmen verarbeitet werden sollen. , wie oft z.B. ein highway=cycleway mit der Bedeutung 'benutzungspflichtiger Radweg' und wie oft mit der Bedeutung 'irgendein Weg auf der hauptsächlich zum Radfahren benutzt wird' vorkommt. wenn ich mit dem Fahrrad unterwegs bin, und das bin ich fast ausschließlich, dann ist das für mich praktisch egal, hauptsache ich kann mit dem Fahrrad dort fahren (gut, fairerweise muss ich dazusagen, dass Verkehrsregeln an meinem Wohnort deutlich freier ausgelegt werden als in Deutschland, und man sich mit dem Fahrrad überhaupt nicht dran halten muss). Bei dem Beispiel ist es wieder eine Frage der Erwartungshaltung. Soll die Realität nur 'in etwa' abgebildet werden oder so genau wie möglich. Vielleicht bin ich da auch zu anspruchsvoll, mag sein. Das ist alles schön und gut, aber es
Re: [Talk-de] Karte mit Öffentlichen Verkehrsmitteln
Am 26. November 2008 19:17 schrieb John07 o...@jonas-krueckel.de: Melchior Moos schrieb: 2008/11/26 John07 o...@jonas-krueckel.de mailto:o...@jonas-krueckel.de Melchior Moos schrieb: Hallo zusammen, ich habe ein update der Karte unter http://81.89.97.206/oepv.html erstellt. - Die Daten sind nun auf dem Stand vom 25.11. - Es gibt einen Zoomlevel mehr, so dass auch Bushaltestellen sichtbar werden - Die rollen forward/backward werden durch kleine Pfeile auf den Linien gekennzeichnet Sehr schön. Permalink wäre noch toll. Ist drin! Danke. Kann es sein, dass du landuse=forest nicht renderst? Es fehlen nämlich diese Wälder. Vllt. beim nächsten mal berücksichtigen. Ansonsten gefällt mir den Kartenstyle irgendwie, sehr ruhig :-) Gruß Jonas Bei vielen Straßenbahnlinien auf einer Strecke werden nur zwei (manchmal 3 angezeigt): http://www.öpnvkarte.de/?lat=48.22lon=16.36zoom=17http://www.xn--pnvkarte-m4a.de/?lat=48.22lon=16.36zoom=17 Hier fährt 37,38,40,41,42 meistens ist nur 40 41 sichtbar. Der N41 fügt sich allerdings schon sehr gut ein. mfg, Kelvan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Frederik Ramm schrieb: Hallo, Sebastian Hohmann wrote: Aber es kann ja irgendwie nicht sein, dass man bei Tags die sehr weit verbreitet sind, nicht genau weiß was sie bedeuten. Das ist keinesfalls so selbstverständlich, wie Du mit dem es kann ja irgendwie nicht sein ausdrückst. Wenn Du mal ganz banale Dinge Deines alltäglichen Lebens betrachtest, dann weisst Du das wenigste genau; in den allermeisten Fällen hilft auch, etwas vage zu wissen oder einfach zu sagen: Hab ich bisher immer so gemacht, hat gut funktioniert, mach ich weiter so. - Wird Dir zum Beispiel auch bei Sprache so gehen, die ist ja doch nun recht weit verbreitet, und dennoch koennen viele Leute selbst Worte aus ihrem aktiven Wortschatz nicht richtig präzise definieren. Bricht deshalb die menschliche Kommunikation zusammen? Nein. Eine Programmiersprache würde so sicherlich nicht funktionieren. Aber anscheinend gibt es unterschiedliche Ansichten, wie OSM aussehen soll. befindlichen Tags so zu definieren und zu dokumentieren, dass man sie nachträglich auch eindeutig automatisiert interpretieren kann. Es ist sicherlich wünschenswert, Tags eindeutig automatisch interepretieren zu können. Aber dieses Ziel ist nicht absolut und hat nicht die höchste Priorität; man muss immer fragen, welcher Preis dafür zu zahlen ist und ob das Projekt sich diesen Preis leisten kann und will. Es ist keineswegs so, dass Tags, die sich nicht eindeutig, sondern nur mit hoher Wahrscheinlichkeit und Heuristik automatisch interpretieren lassen, wertlos sind - lediglich der Aufwand ist höher. Man muss sich allerdings auch fragen, ob es nicht sinnvoll wäre zumindest etwas in Richtung Eindeutigkeit zu arbeiten. Fragt sich auch wie man dann herausfinden soll, welche Interpretation die Richtige ist (oh, schon wieder das böse 'R'-Wort). Sagen wir eben die 'am ehesten der Realität entsprechende'. Man kann also nicht daraus ablesen, wie oft z.B. ein highway=cycleway mit der Bedeutung 'benutzungspflichtiger Radweg' und wie oft mit der Bedeutung 'irgendein Weg auf der hauptsächlich zum Radfahren benutzt wird' vorkommt. Ich weiss, dass sich daran viele Gemüter erhitzen, aber in the grand scheme of things, wie der Engländer sagen würde, ist es kein Thema von überragender Wichtigkeit. Sicherlich nicht, war auch nur ein Beispiel. Vielleicht könnten sich aber auch weniger Gemüter daran erhitzen und die Energie mehr in produktivere Dinge stecken, wenn man eine Lösung dafür finden würde. Die Diskussionen zeigen ja, dass prinzipiell Bedarf dafür besteht (zumindest hierzulande). Ein weiteres Problem, das aber auch mit Entscheidungen zu tun hat, ist die Frage nach 'offiziellen' oder 'empfohlenen' Tags, also letztlich den Map Features. Auch hier gibt es Unklarheiten, wie diese ausgewählt werden oder wer letztlich zu entscheiden hat was in die Map Features kommt. Das ist genauso wie wer letztlich zu entscheiden hat, was auf der OpenStreetMap-Seite in der Wikipedia steht. Gibt es in der Wikipedia nicht Admins, die zumindest in Streitfällen dann schlichten und die Seite erstmal sperren, wenn es in Edit-Wars ausartet? - Es ist nicht klar definiert, wann ein Proposal angenommen ist (und was das bedeutet, siehe vorheriger Punkt). Eben weil der Proposal-Prozess keine formelle Bedeutung hat, ist es auch nicht schlimm, dass das nicht klar definiert ist. Gerade das bemängel ich ja. Wenn der Proposal-Prozess keine formelle Bedeutung hat, dann soll das wenigstens auch auf der Wiki-Seite so stehen. Was da steht erweckt den Eindruck, dass ein erfolgreicher Vote etwas bedeutet. Bleibt noch die Frage wie schon existierende Features verändert werden können. Angenommen man wollte einen Tag genauer oder etwas anders definieren (nachträglich natürlich nur im Notfall, um Unklarheiten auszuräumen). Wie soll man das machen? Der Kern der Sache ist doch, dass man niemandem vorschreiben kann, bei einer Änderung mitzuziehen. So gern Du das vielleicht willst, Du kannst die Mapper in Grossbritannien nicht zwingen, mitzumachen. Also ist das ganze Beharren auf Formalia doch witzlos (aber ich bin im RECHT, so wie ich es mache ist es RICHTIG, ich habe mich an alle REGELN gehalten, mein PROPOSAL wurde angenommen, und nun musst DU auch mitmachen - nö, muss ich nicht). Stimmt, man kann niemand dazu zwingen, einen Tag zu benutzen. Allerdings bringt es doch auch nichts, wenn jeder anders taggt. Wozu gibt es dann überhaupt das Wiki, wenn nicht dazu es für die so 'formell' wie möglich zu dokumentieren, die sich daran orientieren MÖCHTEN. Wenn es nicht gelingt, die Menschen im Projekt von Deiner Idee zu ueberzeugen, dann nuetzt Dir jede formale Prozedur nichts. Umgekehrt verbietet Dir auch niemand, Deine Idee umzusetzen... Wenn mir also im Wiki eine Definition nicht gefällt, soll ich sie einfach ändern? Und was ist wenn die Diskussion zur Ausarbeitung eines neuen Vorschlags oder
Re: [Talk-de] taggen für den Checker - Gehts noch?
Hallo. Am Dienstag, 20. Januar 2009 schrieb Stephan Wolff: In der Literatur schreibt man [sic] um zu kennzeichnen, dass man eine Schreibweise oder eine ungewöhnliche Tatsache genau so und nicht anders meint. In OSM könnten wir sic=yes schreiben. Das ist international, leicht zu merken und schnell zu tippen. Es passt auch für andere unübliche Dinge wie eine Bootstankstelle für die Frederik das Tag validator:ignore=fuel_station_on_water_and_not_near_street einbauen müsste. In der Literatur hat man aber nur die Schreibweise. In OSM haben wir die Schreibweise eines Namens, die Ref-Nummer, die Position, die Tatsache wer mit wem verbunden ist und was weiß ich noch alles. Das alles mit *einem* sic zu kennzeichnen erscheint mir jetzt aber wenig sinnvoll. Gruß, Bernd -- Die ganze Börse hängt nur davon ab, ob es mehr Aktien gibt als Idioten oder mehr Idioten als Aktien. - André Kostolany (ungar. Finanzfachmann) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Oh doch. Ist motorcar inklusive hgv, goods, psv? Je nachdem wie derjenige der die Daten auswertet das sieht, darf ein LKW plötzlich überall durch wo Kraftfahrzeuge gesperrt sind oder auch nicht. naja, jetzt übertreibst Du. Natürlich ist es mit hgv und goods, (wenn da nicht dransteht LKW frei oder so, also hgv=yes), psv hat oft sowieso Sonderregelungen, aber wenn da nicht explizit psv=yes getaggt ist (und es nicht vergessen wurde), dann gilt das auch für psv (wenn dieser nicht z.B. eine Fahrrad-rikscha ist). Übrigens darf ein LKW da trotzdem nicht durch, auch wenn die OSM-Daten ihm dazu raten, und wenn der Router so schlecht ist, dass er es einem LKW trotzdem empfehlen würde, dann wird er auch nicht lange benutzt werden. Du hast ja selbst schon erkannt, dass mit motorcar eigentlich Kfz gemeint sind ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Martin Koppenhoefer schrieb: Oh doch. Ist motorcar inklusive hgv, goods, psv? Je nachdem wie derjenige der die Daten auswertet das sieht, darf ein LKW plötzlich überall durch wo Kraftfahrzeuge gesperrt sind oder auch nicht. naja, jetzt übertreibst Du. Natürlich ist es mit hgv und goods, (wenn da nicht dransteht LKW frei oder so, also hgv=yes), psv hat oft sowieso Sonderregelungen, aber wenn da nicht explizit psv=yes getaggt ist (und es nicht vergessen wurde), dann gilt das auch für psv (wenn dieser nicht z.B. eine Fahrrad-rikscha ist). Übrigens darf ein LKW da trotzdem nicht durch, auch wenn die OSM-Daten ihm dazu raten, und wenn der Router so schlecht ist, dass er es einem LKW trotzdem empfehlen würde, dann wird er auch nicht lange benutzt werden. Du hast ja selbst schon erkannt, dass mit motorcar eigentlich Kfz gemeint sind ;-) Eigentlich ja, aber erstaunlicherweise habe ich schon einige Male gelesen, dass statt lediglich motorcar=no auch noch hgv und goods gesetzt werden sollen. Ich denke nicht dass es bei sowas um persönliche Präferenzen geht, die man sowieso nicht verändern kann, sondern eher um eine der möglichen Interpretation der Tags. Das ließe sich durch besseres Erklären im Wiki lösen. Ich weiß aber leider nicht, wie man solche Änderungen anbringen soll. Soll man das einfach ändern und warten ob sich jemand beschwert (so wie ich es teilweise auch schon gemacht habe)? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Hi, Am 21. Januar 2009 00:54 schrieb Detlef Reichl detlef.rei...@gmx.org: implementiert werden sollten. Was dabei raus kommt sieht man bei WikiPedia. Dort muß derweil auch die kleinste Änderung an den meisten (alle?) Artikeln von den Admins abgenickt werden. Das tötet die Motivation vieler Leute. Bitte nur so etwas schreiben, wenn du dir auch sicher bist, danke. (Hint: Es ist nicht der Fall und die gesichteten Versionen, die du möglicherweise ansprichst, funktionieren anders). Um Verunstaltungen rückgängig machen zu können sollte es simple Werkzeuge geben, mit denen man auf eine beliebigen Versionsstand für eine Objekt oder einen Bereich zurückgehen kann. Der Vorteil von Wikis liegt zum Teil darin, dass das Rückgängigmachen von Vandalismus in der Regel einfacher ist, als die Durchführung desselben. Dies ist derzeit bei OSM leider nicht der Fall. Um genau zu sein wundert es mich immer wieder, dass sich für OSM noch niemand ähnliche fiese Vandalismus-Techniken hat einfallen lassen, wie sie in der WP zur Anwendung kommen. Tschüss, Tim. -- http://wikipedistik.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Es ist keineswegs so, dass Tags, die sich nicht eindeutig, sondern nur mit hoher Wahrscheinlichkeit und Heuristik automatisch interpretieren lassen, wertlos sind - lediglich der Aufwand ist höher. Man muss sich allerdings auch fragen, ob es nicht sinnvoll wäre zumindest etwas in Richtung Eindeutigkeit zu arbeiten. Fragt sich auch wie man dann herausfinden soll, welche Interpretation die Richtige ist (oh, schon wieder das böse 'R'-Wort). Sagen wir eben die 'am ehesten der Realität entsprechende'. Man kann mit OSM-Daten momentan (wirklich, real, gibt es schon, ist nicht nur ein Hirngespinst): * allgemeine Karten malen * Spezialkarten malen (Fahrradkarten, Wanderkarten, ...) * Routen finden * ein richtiges Auto-Navi füttern * Orte finden * POIs (Parkplätze, Museen, ...) finden und bestimmt noch viel, viel mehr was ich selbst gar nicht mitbekommen habe. Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Der Wunsch nach Standardisierung und Reglementierung kommt hier mindestens alle 3 Monate in der Ausführlichkeit wie du es schreibst. Frederik reagiert darauf mit immer wieder der gleichen Antwort. *Diese* Ruhe ist beneidenswert, nicht das Vertrauen auf die Selbstregulierung der OSM-Daten. Bei OSM entscheiden momentan in erster Linie die verwendeten Tools, was benutzt wird. Seit es den OSM-Inspector gibt, setzt jeder ein addr:postcode an jede einzelne seiner Adressen obwohl es noch nicht lange her ist, dass man das für unnötige Daten hielt. Seit es JOSM-Presets gibt, orientieren sich viele Leute daran. Seit es OpenRouteService bzw. Yournavigation gibt, kann man richtig praktisch sehen, wo Wege noch nicht verbunden sind obwohl es in der gemalten Karte so aussieht. Seit es Garys Checks gibt, gilt seine Interpretation mancher Dinge eben für einen großen Teil der Leute als Richtwert. So lange es diese Programme schaffen, mit OSM-Daten sinnvolle Dinge zu machen, sehe ich echt kein Problem. Klar wird es immer eine Möglichkeit geben, Daten noch genauer oder noch besser, vielleicht sogar richtiger einzutragen. Sobald diese weitere Genauigkeit oder diese richtigeren Tags jemand braucht, wird er eine Anwendung schreiben und dann werden viele Leute sehen, dass man wirklich was damit anfangen kann und ihre Arbeit auf genau das umstellen was dieses Programm auslesen will. Ach ja: Was noch niemand bei all diesen Konsolidierungsvorschlägen genauer sagen konnte: Wer ist denn der man, der alles festlegt? Wer ist denn dafür zuständig, dass das was da festgelegt wird, auch richtig ist? Wird ein Gremium gewählt? Ist es auch okay, wenn da kein einziger aus Deutschland dabei ist und die Engländer uns ihre lokalen Gepflogenheiten aufs Auge drücken? Ich glaube zwar nicht, dass jeder der so etwas vorschlägt am liebsten selbst das Gremium wäre, aber ich glaube dass bei Missfallen der Entscheidungen man sich einfach nicht dran hält bzw. vermutlich sofort das Projekt wieder verlässt. Dann hat man wieder nichts gewonnen. Gruß, Bernd -- Columbus hatte in Wirklichkeit vier Schiffe - das vierte segelte über die Kante signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Um genau zu sein wundert es mich immer wieder, dass sich für OSM noch niemand ähnliche fiese Vandalismus-Techniken hat einfallen lassen, wie sie in der WP zur Anwendung kommen. wie kommst Du denn da drauf? Die haben wir nur noch nicht entdeckt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Tim 'avatar' Bartel: Am 21. Januar 2009 00:54 schrieb Detlef Reichl detlef.rei...@gmx.org: implementiert werden sollten. Was dabei raus kommt sieht man bei WikiPedia. Dort muß derweil auch die kleinste Änderung an den meisten (alle?) Artikeln von den Admins abgenickt werden. Das tötet die Motivation vieler Leute. Bitte nur so etwas schreiben, wenn du dir auch sicher bist, danke. (Hint: Es ist nicht der Fall und die gesichteten Versionen, die du möglicherweise ansprichst, funktionieren anders). Diese gesichteten Versionen haben dazu geführt, dass ich seither keine Wikipedia-Änderungen mehr mache. Ich wollte eine aktuelle Entwicklung in meinem Heimatort in Wikipedia eintragen und nach einem Tag Wartezeit wurde meine Änderung von jemandem der sich scheinbar nicht mit dem Ort auskennt umformuliet so dass die gesichtete Version danach wesentlich falscher war als vorher. Wie sehr sich Detlef mit der Wikipedia auskennt weiß ich nicht, ich kenne mich nicht besonders damit aus, aber seine Aussage dass das die Motivation tötet ist absolut treffend. Gruß, Bernd -- Spontaneität muß wohlüberlegt sein. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte (im neuen Gewand)
2009/1/20 Claudius Henrichs claudiu...@gmx.de Am 20.01.2009 19:17, André Reichelt: Bei mir funktioniert die Adresse nicht. Hat wer nen Link? Andere Variante: http://osmc.broadbox.de/ Gruß, Claudius auch gut. Ich würde die roten Punkte in der Übersichtskarte (ausklappend) auch als links nutzen (für die Region). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Bernd Wurst schrieb: Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Es ist keineswegs so, dass Tags, die sich nicht eindeutig, sondern nur mit hoher Wahrscheinlichkeit und Heuristik automatisch interpretieren lassen, wertlos sind - lediglich der Aufwand ist höher. Man muss sich allerdings auch fragen, ob es nicht sinnvoll wäre zumindest etwas in Richtung Eindeutigkeit zu arbeiten. Fragt sich auch wie man dann herausfinden soll, welche Interpretation die Richtige ist (oh, schon wieder das böse 'R'-Wort). Sagen wir eben die 'am ehesten der Realität entsprechende'. Man kann mit OSM-Daten momentan (wirklich, real, gibt es schon, ist nicht nur ein Hirngespinst): * allgemeine Karten malen * Spezialkarten malen (Fahrradkarten, Wanderkarten, ...) * Routen finden * ein richtiges Auto-Navi füttern * Orte finden * POIs (Parkplätze, Museen, ...) finden und bestimmt noch viel, viel mehr was ich selbst gar nicht mitbekommen habe. Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Kommt wohl auf die Ansprüche an. Wenn es einem nicht wichtig ist, ob ein Weg mit Anlieger frei für Fahrräder freigeben ist oder nicht, weil man sowieso durchfährt, dann reichen die Daten selbstverständlich. Und wenn man auch sonst keine allzu hohe Ansprüche hat. Aber die meisten der von dir aufgelisteten Dinge hat mit den von mir bemängelten Dingen nicht allzuviel zu tun. Die Karten sehen so und so gut aus, egal ob die Daten stimmen oder nicht. Routing funktioniert auch. Fragt sich halt bloss welche Ansprüche man daran stellt. Ob man als z.B. zwischen Feinheiten wie (Reise)Bus-Routing und PKW-Routing unterscheiden will. Der Wunsch nach Standardisierung und Reglementierung kommt hier mindestens alle 3 Monate in der Ausführlichkeit wie du es schreibst. Frederik reagiert darauf mit immer wieder der gleichen Antwort. *Diese* Ruhe ist beneidenswert, nicht das Vertrauen auf die Selbstregulierung der OSM-Daten. Also ich lese nicht alle 3 Monate etwas davon. Übrigens muss Frederik darauf auch nicht antworten, wenn es ihm etwas ausmacht. Bei OSM entscheiden momentan in erster Linie die verwendeten Tools, was benutzt wird. Wer ist denn der man, der alles festlegt? Wer ist denn dafür zuständig, dass das was da festgelegt wird, auch richtig ist? Wer das aktuell ist hast du ja selbst geschrieben. Aber warum wird sich hier denn so dagegen gewehrt, die OSM Daten etwas besser zu machen? Es geht doch darum es für die Mapper einfacher zu machen. Anstatt in den JOSM Presets 'vorzuschreiben' was benutzt wird, würde ich es eben auch gerne im Wiki machen. Was dann letztlich benutzt wird, ist dann Sache der Mapper. Um aber im Wiki etwas zu erreichen, braucht es einfach klare Regeln. Oder man schafft das Accepted/Rejected Proposal gleich ab und schreibt nur das Ergebnis der Abstimmung als Stimmungsbarometer der Interessierten hin. Bleibt trotzdem noch die Frage was in die Map Features kommt. Wenn es nicht nach dem Voting geht, nach was dann? Das ist ein konkretes Problem, das nunmal so oder so entschieden werden muss. Langsam habe ich keine große Lust mehr, mich im Wiki zu engagieren. Übrigens haben auch schon Leute aufgrund der Uneindeutigkeit der Daten OSM den Rücken gekehrt. Vielleicht sollte man gleich auf die Anfänger-Seite schreiben, dass man nicht allzuviel Genauigkeit erwarten sollte, wenn man nicht vorhat eine konkrete Anwendung zu programmieren, die diese speziellen Daten braucht (eigentlich dachte ich ja OSM sammelt Daten auch erstmal unabhängig davon ob sie schon irgendwo dargestellt werden). Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Frederik Ramm frede...@remote.org writes: Ich denke, bei sowas wie bicycle=yes und motorcar=no gibt es relativ wenig Deutungs-Unterschiede. Relativ wenig kann aber eine ganze menge sein. Das yes kann von physikalisch möglich bis rechtlich erlaubt stehen. Wenn man dann noch bedenkt, dass bicycle von rennrad bis mountainbike reicht, dann kann physikalisch möglich auch schon wieder vieles bedeuten. Du hast aber recht, dass die deutung sicherer wird, wenn weitere angaben wie physikalische beschaffenheit und verkehrszeichen hinzukommen. Es ist nur mühsam, das alles auszuwerten. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Kommt wohl auf die Ansprüche an. Wenn es einem nicht wichtig ist, ob ein Weg mit Anlieger frei für Fahrräder freigeben ist oder nicht, weil man sowieso durchfährt, dann reichen die Daten selbstverständlich. Und wenn man auch sonst keine allzu hohe Ansprüche hat. Bisher hat scheinbar niemand genau diese Ansprüche, die du hast. Aber die meisten der von dir aufgelisteten Dinge hat mit den von mir bemängelten Dingen nicht allzuviel zu tun. Die Karten sehen so und so gut aus, egal ob die Daten stimmen oder nicht. Routing funktioniert auch. Fragt sich halt bloss welche Ansprüche man daran stellt. Ob man als z.B. zwischen Feinheiten wie (Reise)Bus-Routing und PKW-Routing unterscheiden will. Ich glaube gerne, dass routing für LKW und Reisebusse bald irgendwo mal mit diesen Daten gemacht wird. Ob Anlieger frei für Fahrräder gilt oder nicht, ist dafür irrelevant. Sobald das jemand macht, wird klar werden, dass maxweight=* und maxheight=* sowie ein paar ähnliche Tags nicht wirklich flächendeckend eingetragen wurden. Anliegerstraßen sind in der großen Masse aller Straßen ein verschwindend geringer Anteil. Und auch wenn unser Anspruch die Perfektion ist, so sind wir doch schonmal froh, diese Straßen überhaupt drin zu haben. Die kommerziellen Alternativen haben die oft überhaupt nicht drin. Wer ist denn der man, der alles festlegt? Wer ist denn dafür zuständig, dass das was da festgelegt wird, auch richtig ist? Wer das aktuell ist hast du ja selbst geschrieben. Nein. Es legt bisher niemand etwas fest sondern mit funktionierenden Anwendungen kann man eine große Zahl an Mitstreitern motivieren, freiwillig am gleichen Strang zu ziehen. Aber warum wird sich hier denn so dagegen gewehrt, die OSM Daten etwas besser zu machen? Du hast es immer noch nicht verstanden: Weil das besser nicht so konkret definierbar ist! Um aber im Wiki etwas zu erreichen, braucht es einfach klare Regeln. Nein. Oder man schafft das Accepted/Rejected Proposal gleich ab und schreibt nur das Ergebnis der Abstimmung als Stimmungsbarometer der Interessierten hin. Bleibt trotzdem noch die Frage was in die Map Features kommt. Wenn es nicht nach dem Voting geht, nach was dann? Das ist ein konkretes Problem, das nunmal so oder so entschieden werden muss. Langsam habe ich keine große Lust mehr, mich im Wiki zu engagieren. Das Wiki ist eine Daten-Halde, in dem man suchen kann wenn man Tags für irgendwas braucht und in das man eintragen kann, was man selbst so benutzt. Außerdem ist es eine rudimentäre Anleitung für Einsteiger und Dokumentation für unzählige Programme aus dem OSM-Umfeld. Es ist kein Gesetzbuch oder irgend etwas was ein Mapper *braucht*. Seit es Presets gibt, braucht man noch nichtmal die Map-Features-Seite unbedingt wenn man mit OSM anfängt. Wenn du dich nicht im Wiki engagieren möchtest, lass es. Wenn du etwas verbessern willst: Mach es. Wenn du viel verbessern willst und keine Leute verprellen möchtest, leg jeweils eine neue Seite an und verweise auf der Diskussions-Seite der alten Variante auf deinen Neuvorschlag. Seit der Einfühung von highway=path mit der Brechstange sollte jedem klar sein, wie viel Bedeutung das Wiki hat und wie ernst zu nehmen das ist. Man kann aber auch ganz prima mappen ohne das Wiki zu benutzen. Gruß, Bernd -- Mit Hacken ist das wie mit dem Blues. Wer fragen muß, was Hacken ist, wird es nie verstehen. - Felix von Leitner signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte (im neuen Gewand)
Das sieht richtig gut aus. Kannst du das bitte nach und nach auf ganz Deutschland ausbauen. Ciao André 2009/1/21 Claudius Henrichs claudiu...@gmx.de: Am 20.01.2009 19:17, André Reichelt: Bei mir funktioniert die Adresse nicht. Hat wer nen Link? Andere Variante: http://osmc.broadbox.de/ Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik Tools kaputt?
Michael Schmitt schrieb: Was ist mit den Tools von Geofabrik los? Unter http://tools.geofabrik.de bekomme ich zwar die Toolsseiten mit dem unterlegten Layern angezeigt, aber statt der Tool-Layer sehe ich eine Masse Text, die nach Fehlermeldungen für Java aussehen. Leider läßt sich den Text nicht mit dem Cutpaste fangen. Benutze Firefox 3.0.5 unter XP mit Java 6 Update 7. (Cache schon geleert.) Heute morgen funktioniert es wieder. mikes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wieviel Plattenplatz brauchen die Tiles für Deutschland?
Hallo Liste, bin gerade dabei mit Kosmos herumzuspielen und habe als Beispiel mal die kompletten Daten von Rheinland-Pfalz in den Zoomstufen 0-17 berechnen lassen. Dabei werden 1779 Ordner mit 132 Dateien angelegt. Gesamtgröße ~3,6GB. Gebraucht hat mein Rechner dafür etwas über 24h Zoom 01,85kB Zoom 11,94kB Zoom 22,29kB Zoom 32,40kB Zoom 42,93kB Zoom 57,03kB Zoom 614,3kB Zoom 729,7kB Zoom 894,8kB Zoom 9293kB Zoom 101,45MB Zoom 114,08MB Zoom 1212,8MB Zoom 1335,6MB Zoom 1494,8MB Zoom 15265MB Zoom 16783MB Zoom 172450MB Das kommt mir jetzt ziemlich viel vor. Wieviele Terabytes verbraten den die Tiles von planet.osm in t...@h oder Mapnik? Tschuess Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo, Sebastian Hohmann wrote: Gibt es in der Wikipedia nicht Admins, die zumindest in Streitfällen dann schlichten und die Seite erstmal sperren, wenn es in Edit-Wars ausartet? Die schlichten, soweit ich weiss, allenfalls den Prozess, also so nach dem Motto jetzt einigt Euch halt, aber die entscheiden nicht, was richtig ist. Wenn es nicht gelingt, die Menschen im Projekt von Deiner Idee zu ueberzeugen, dann nuetzt Dir jede formale Prozedur nichts. Umgekehrt verbietet Dir auch niemand, Deine Idee umzusetzen... Wenn mir also im Wiki eine Definition nicht gefällt, soll ich sie einfach ändern? Wenn eine Definition so vage ist, dass sie Auslegungsspielraum hat, dann lege sie so aus, wie Du es fuer richtig haeltst. Dazu musst Du sie nicht aendern. Wenn Du das gesamte Konzept fuer unsinnig haeltst, dann denke Dir was eigenes brauchbares aus und verwende das; dokumentiere es ggf. auf einer eigenen Wikiseite (vielleicht zunaechst im User-Namensraum, wenn es sehr esoterisch ist). All diese Moeglichkeiten stehen Dir offen, ohne dass Du andere nach Deiner Pfeife tanzen lassen musst. Ich denke, bei sowas wie bicycle=yes und motorcar=no gibt es relativ wenig Deutungs-Unterschiede. [...] Oh doch. Ist motorcar inklusive hgv, goods, psv? Je nachdem wie derjenige der die Daten auswertet das sieht, darf ein LKW plötzlich überall durch wo Kraftfahrzeuge gesperrt sind oder auch nicht. Das ist halt sowas, wo die Programmierer sich etwas mehr auf den Charakter von OSM einlassen muessen. Ist es realistisch, eine Strasse zu haben, die fuer PKW gesperrt, fuer LKW aber frei ist? Sollte der Router in so einem Fall eventuell lieber auf der Seite der Vorsicht irren? (Ist uebrigens hgv nicht identisch mit goods?) Mir geht es weniger darum irgendjemand dazu zu zwingen es genauso zu machen, wie es im Wiki steht, sondern eher darum, dass die Mapper meist garkeine Möglichkeit haben, sich an etwas zu orientieren. Ich mappe ja selbst wie ich es am logischsten finde. Man müsste sich aber weniger selbst zusammenraten, wenn Manches im Wiki klarer definiert wäre. Wem die Definition nicht gefällt, mappt natürlich trotzdem wie er es für besser hält. Dann brauchen wir aber keinen Prozess, sondern einfach eine einzige Person, die einfach gut ist, oder von mir aus ein Team von Leuten, die sich im Rahmen der allgemein akzeptieren vagen Regeln konkrete Tagging-Howtos ausdenken (und das passiert ja auch schon vielerorts im Wiki, z.B. dort wo jemand angefangen hat, zu jedem Verkehrsschild aufzuschreiben, wie man das seiner Ansicht nach taggen sollte). Diese Leute koennen dann ja eine stimmige Interpretation/Empfehlung aufschreiben, und jeder, der das gut findet, kanns uebernehmen. Wenn es in einem anderen Land andere solche Leute gibt, die sich etwas anders entscheiden - was solls. 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-de
Re: [Talk-de] Wieviel Plattenplatz brauchen die Tiles für Deutschland?
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Michael Buchberger: Das kommt mir jetzt ziemlich viel vor. Wieviele Terabytes verbraten den die Tiles von planet.osm in t...@h oder Mapnik? http://wiki.openstreetmap.org/wiki/Servers/tileserv http://wiki.openstreetmap.org/wiki/Servers/titan Folgendes ist zu bedenken: 1. Die Zahl der Tiles steigt exponenziell mit der Zoomstufe an. Dadurch ist es klar, dass man bei einer Steigerung um ein paar Zoomstufen eine gigantisch höhere Speichermenge braucht. 2. Alles was großflächiges Wasser ist, muss nicht gerendert werden. Eine Markierung das ist Meer reicht und es muss nur ein blaues Bild gespeichert werden. So spart man sich mal deutlich über die Hälfte der Erdoberfläche. 3. Mapnik rendert teilweise On-demand. Kacheln die lange nicht mehr angeschaut wurden, werden verworfen und auf Anforderung neu gerendert. Dieses Neurendern dauert nur ein paar Sekunden und passiert immer dann wenn du das Bild More OSM coming soon siehst. Nach einem Reload siehst du dann das Ergebnis. Prinzipiell (mit einer noch schnelleren Maschine dahinter) könnte Mapnik auch komplett live rendern und es müssten gar keine Kacheln auf Vorrat gespeichert werden. 4. ti...@home rendert nur wo es was zu rendern gibt. Das Kommando ein Tileset zu rendern kommt manuell für eine bestimmte Region oder durch einen Bot der die Änderungen an der Datenbank überwacht und schaut wo sich was geändert hat. Man kann also nicht R-P einfach auf die Erdoberfläche hochrechnen für den Speicherverbrauch, aber insbesondere bei t...@h ist die Menge dennoch riesig: Laut http://munin.openstreetmap.org/openstreetmap/tah.openstreetmap-df.html sind 90% der 2 x 500 GB belegt, macht 900 GB Platz für bunte Bildchen. Gruß, Bernd -- Alles Schöne im Leben hat einen Haken: Es ist unmoralisch, illegal oder es macht dick. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
