Re: [Talk-de] Mehrere Dinge zusammenfügen OK?
Am 04.05.2010 00:55, schrieb AssetBurned: gut jetzt könnte man die frage aufwerfen, mappen wir für den renderer oder nicht? Das von dir beschriebene Problem ist eindeutig ein Renderer-Fehler. osm2pgsql erzeugt zB. extra für den Mapnik im Centeroid von Parklätzen eine Parkplatz-Node, um dort ein Icon hin malen zu können. So können auch andere Renderer damit umgehen. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Dinge zusammenfügen OK?
Am Dienstag 04 Mai 2010 00:55:13 schrieb AssetBurned: allerdings sehe ich schon ein problem bei der sache. OSM2Go als editor zeigt mir zum beispiel ein einzelnen node der als bank getaggt wurde als banken symbol an. wenn ich allerdings ein gebäude als bank tagge dann sehe ich erstmal nur ein gebäude. gut jetzt könnte man die frage aufwerfen, mappen wir für den renderer oder nicht? ich weiß ja nicht wie es mit anderen geräten ausschaut ob da auch diese probleme exsistieren. naja, einen punkt auszuwerten ist halt wesentlich einfacher, als sich den schwerpunkt einer flaeche rauszuziehen. selbst dann ist nicht sichergestellt, dass das icon oder die beschriftung auch auf dem gebaeude rauskommt, grade bei unfoermigen gebilden. auch fuer router kann das hilfreich sein, um den nutzer bei einem groesseren gebaeude auf die richtige seite zu lotsen... deshalb halte ich es durchaus fuer sinnvoll, den poi zusaetzlich als punkt mitten im gebaeude oder an einem anderen sinnvollen ort anzugeben (z.B. in der naehe des eingangs). optimal waere natuerlich noch eine art verknupfung (relation?) mit dem gebaeude, damit nicht zwei pois entstehen, wenn ein programm sowohl gebaeude als auch punkt auswertet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie kann man besseres Autorouting fuer Fahrradfaher erreichen. Ideen und Konstruktive Vorschlaege
Am Montag 03 Mai 2010 16:54:22 schrieb Dirk-Lüder Kreie: *Klassifizierte Meinungen* Fuer klassifizierte Meinungen von Personen die sich mit Autorouting und OSM naeher auseinandergesetzt haben, oder Routing Algorithmen entwickeln, habe ich hier eine Voice your Suport/Objection Page eroeffnet, da ich einfach davon ausgehe, dass jene die am lautesten dagegen Schreiben, NULL praktische Erfahrung mit Autorouting haben. [snip] Du kannst mappern höchstens Empfehlungen geben, wie etwas gemappt wird. auch wenn sich alle Routingexperten zusammensetzen und das ideale Taggingmodell für automatische Routenerzeugung erstellen, was aber für nichteingeweihte völlig unverständlich bleibt, wird es nicht benutzt werden. Genau das ist ein Thema, wo sich osm gerne im Kreis dreht: Ich halte es durchaus fuer sinnvoll, wenn sich in erster Linie die Entwickler (und meinetwegen Leute, die in bestimmten Fachbereichen fit sind) um das Tagging-Schema kuemmern, denn die muessen schliesslich damit arbeiten. Der Otto-Normal-Mapper wird durch die Editoren von dieser Tagging-Ebene abgekoppelt, und kriegt im besten Falle die (komplizierten) Tagging-Schemata gar nicht zu Gesicht... Irgendwann muss OSM auch mal erwachsen werden... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] potlatch und große Relationen
Am 04.05.2010 01:44, schrieb Heiko Jacobs: Potlatch quittiert doch das erfolgreiche Hochladen mit einer Meldung. Warte doch einfach daruaf. Eigentlich quititert er so direkt nicht ... Wenn man was geändert hat und das ist noch selektiert, also noch kein Hocladen begonnen, mosert potlatch rum, wenn man via View rausgehen will. Wenn das Hochladen schon begonnen wurde und die Eieruhr eiert noch, kommt glaub keine Beschwerde und dier Eieruhr hört nur irgendwann auf zu eiern, wenn man drin bleibt. Das Eiern kann man leicht übersehen ... Große Relationen im live-Modus von Potlatch zu bearbeiten hat aber auch schon seinen ganz eigenen Charme... -- Dirk-Lüder Deelkar Kreie Bremen - 53.0901°N 8.7868°E signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ausdrucken von wanderkarten - kennt jemand etwas
Am 04.05.10 07:11, schrieb Jan Tappenbeck: Am 04.05.2010 07:09, schrieb Jan Tappenbeck: Moin ! wer mich kennt weiß das ich mich mit dem Projekt Jakobsweg beschäftige - was immer noch fehlt ist die Chance Karten den Relationen folgend zu erstellen. Nun beschäftige ich mich schon seit längerem damit ein Tool zu erschaffen (lassen) das auf Basis von Tiles Karten im A4-Format erstellt und diese zum Ausdruck aufbereitet. Es sollen bestehende Tiles genutzt werden - kein eigener Render integriert werden um verschiedene Fachausrichtungen einfach nutzen zu können. Bevor man mit der Erschaffung beginnt sollte man natürlich erst einmal recherchieren ob es soetwas schon gibt um das Rad nicht neu zu erfinden. Nun die Frage - kennt jemand ein solches Tool schon ? Wenn einer in diesem Zusammenhang entsprechende Ideen / Anforderungen hat, dann bitte mitteilen. Die Druckzusammenstellung von Quantum GIS sollte da schon zielführend sein. Quantum GIS kann auch Tiles von der Festplatte laden, wenn man denen ein Worldfile verpasst. das lässt sich aus dem Ordner- und Dateinamen automatisch generieren. Ein WMS-Dienst mit OSM-Daten wäre für Quantum GIS natürlich einfacher, kostet aber gegebenenfalls. Alternativen: Bigmaps, viking, QlandkarteGT. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einbahnstraßen [War: Wie kann man besseres Autorouting fuer Fahrradfaher erreichen. Ideen und Konstruktive Vorschlaege]
On Mon, May 03, 2010 at 05:38:17PM +0200, Raimond Spekking wrote: Nun aber mal generel zu Einbahnstraßen. In meinem Ort gibt es viele Einbahnstraßen, die für Radfahrer auch in der entgegengesetzten Richtung ein explizites erlaubt-Schild drunter haben. [...] wie taggt man sowas? cycleway=opposite und verwandte Werte, siehe http://wiki.openstreetmap.org/wiki/DE:Key:cycleway Es gibt dort keinen Radweg und damit trifft cycleway nicht zu. Es ist schlicht eine Einbahnstraße an deren Schild eine Freigabe für Radfahrer vermerkt ist. Es gibt *keinen* separat gekennzeichneten Radweg (weder auf der einen noch auf der anderen Seite). 2 Möglichkeiten: 1. Falsch gemappt: Selber richtig mappen, hilfsweise einen Eintrag beim OpenStreetBugs Ich habe das Mapping überprüft, die Einbahnstraße war markiert. 2. Richtig gemappt, aber falsch geroutet: Beim Hersteller der Routingssoftware. Ist der besagte Hersteller der Routingsoftware nun OpenMTBMap oder Garmin (ich habe das Routing im Etrex Vista benutzt)? Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] potlatch und große Relationen
Am 04.05.10 01:44, schrieb Heiko Jacobs: Claudius schrieb: Wenn du in einer Autobahn eine Brücke reinbastelst teilst du ja meist einen bestehenden Weg. Wenn dieser mehrere hundert Knoten enthält müssen die für den so neu erstellten Restweg (also den Teil ohne Brücke) erneut übertragen werden. Ich meine, wenn die Knoten nicht verschoben werden, wird da nix übertragen ... Davon abgesehen ist die Geometrie der Autobahnen hier eher grob und geringknotig und wegen vieler Brücken sind die ways auch recht kurz ... Das kann's nicht sein, während die Relationen vermutlich wirklich riesig sind (A5 längs durch Deutschland und bei der einen Brücke eine, bei der anderen zwei Europastraßen...) Genau da ist das Problem: Die Mitglieder in der Relation sind sortiert, und wenn du einen Weg aufteilst, wird das neue Wegstück dazwischengeschoben. Dazu müssen eben alle nachfolgenden Elemente um eins nach hinten verschoben werden. Auch wenn das nur auf dem Server passiert, dauert das. In josm übrigens genauso. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einbahnstraßen [War: Wie kann man besseres Autorouting fuer Fahrradfaher erreichen. Ideen und Konstruktive Vorschlaege]
On Mon, May 03, 2010 at 06:11:03PM +0200, Felix Hartmann wrote: Ich werte in der Openmtbmap alle oneway Regeln aus, sehe es aber als praktischer an, mit geringer Prioritaet auch generell gegen Einbahnen von Nebenstraßen (also nicht tertiary oder groeßer) zu routen, da es in der Praxis halt Sinn macht auch mal gegen eine Einbahn zu fahren oder zur Not halt zu schieben. Ob das erlaubt ist haengt von lokalen Gesetzen ab, die mich aus der Ferne aber nicht interessieren. Das klingt sehr sinnvoll und würde ich so auch unterstützen. Ich werde die Sache noch mal mit ganz aktuellen Karten beobachten (ich komme dort sehr oft lang). Am gegebenen Ort beträgt der Umweg über die korrekte Richtung nur wenige Meter. Wenn sich das in der beobachteten Form wiederholt, könnte ich das mal als Testfall für Einbahnstraßen-Routing diskutieren. Aber klarerweise ist die Prioritaet niedriger, sprich nur bei deutlichen Verkuerzungen der Route (da spielt aber natuerlich der Algo mit), sollte gegen die Einbahn geroutet werden. Auswerten tu ich sogar so Sachen wie cycleway:left=opposite_track (was in Richtung Gegen die Einbahn natuerlich zu einer fetten abwertung fuehrt.) OK. Ich sehe gerade bei den Features, daß mein in der Eingangsmail beschriebenes Problem mit Fahrradfahrern entgegen der Einbahnstraße doch mit cycleway=opposite beschrieben wird (halt nur ohne '_track'). Ich werde das mal anpassen. Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie kann man besseres Autorouting fuer Fahrradfaher erreichen. Ideen und Konstruktive Vorschlaege
Am 04.05.2010 01:28, schrieb Heiko Jacobs: Eine andere Frage: wird beim Routing schon die Zugehörigkeit zu einer Fahrradrouten-Relaion berücksichtigt? Wenn der way Teil der Deutschlandroute 2, des Enztal-Stromberg-Radwegs oder der lokalen Route 4711 ist, ist das ja auch schon eine Aussage ... Moin, es gibt in YOURS (http://yournavigation.org/) einen Knopf Bicycle(Routes) der genau das bewirken soll, allerdings bei meinem letzten Test noch nicht funktionierte. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: Einbahnstraßen [War: Wie ka nn man besseres Autorouting fuer Fahrradfaher errei chen. Ideen und Konstruktive Vorschlaege]
On Mon, May 03, 2010 at 06:58:03PM +0200, Thomas Wedekind wrote: cycleway=opposite; natürlich muss die Hauptrichtung stimmen, sonst Way-Richtung ggf. umkehren. Ich hätte mich nur mal noch ein paar weitere Straßen ansehen müssen - an manchen ist das schon dran (nur eben nicht bei allen). Übrigens bin ich auch schon mal verkehrtherum durch eine im OSM getaggte Einbahnstraße geroutet worden. Von welchem Programm? Direkt auf dem Garmin Etrex Vista mit OpenMTBmap Karten. Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einbahnstraßen [War: Wie kann man besseres Autorouting fuer Fahrradfaher erreichen. Ideen und Konstruktive Vorschlaege]
Moin, Andreas Tille schrieb: On Mon, May 03, 2010 at 05:38:17PM +0200, Raimond Spekking wrote: cycleway=opposite und verwandte Werte, siehe http://wiki.openstreetmap.org/wiki/DE:Key:cycleway Es gibt dort keinen Radweg und damit trifft cycleway nicht zu. Es ist schlicht eine Einbahnstraße an deren Schild eine Freigabe für Radfahrer vermerkt ist. Es gibt *keinen* separat gekennzeichneten Radweg (weder auf der einen noch auf der anderen Seite). ja, genau das will cycleway=opposite ausdrücken, da es im Gegenrichtungs-Value schließlich keinen keinen seperatenRadweg angibt ... ;-) (Dafür stehen dann ja opposite_lane und opposite_track.) Das aber der Tag cycleway an sich schon einen seperaten Radweg oder zumindest seperateSpur kennzeichnet - dieser Widerspruch (wie Du zu recht erkannt hast) - wurde einfach per Wiki-Definiton geklärt - und damit basta ;-). Es ist halt ein seperater Radweg in Gegenrichtung, der nicht seperat ist. ;-) (Ob jener Widerspruch am Anfang nicht bedacht wurde oder bereits bewußt in Kauf genommen wurde, weiß ich nicht.) (bicycle=opposite wäre ja auch eine Möglichkeit, aber diese einfache Möglichkeit hat wohl bereits mit 259:5190 verloren...) (Stand August 2009 OSMdoc) Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einbahnstraßen [War: Wie kann man besseres Autorouting fuer Fahrradfaher erreichen. Ideen und Konstruktive Vorschlaege]
On 04.05.2010 09:51, Georg Feddern wrote: Moin, Andreas Tille schrieb: On Mon, May 03, 2010 at 05:38:17PM +0200, Raimond Spekking wrote: cycleway=opposite und verwandte Werte, siehe http://wiki.openstreetmap.org/wiki/DE:Key:cycleway Es gibt dort keinen Radweg und damit trifft cycleway nicht zu. Es ist schlicht eine Einbahnstraße an deren Schild eine Freigabe für Radfahrer vermerkt ist. Es gibt *keinen* separat gekennzeichneten Radweg (weder auf der einen noch auf der anderen Seite). ja, genau das will cycleway=opposite ausdrücken, da es im Gegenrichtungs-Value schließlich keinen keinen seperatenRadweg angibt ... ;-) (Dafür stehen dann ja opposite_lane und opposite_track.) Das aber der Tag cycleway an sich schon einen seperaten Radweg oder zumindest seperateSpur kennzeichnet - dieser Widerspruch (wie Du zu recht erkannt hast) - wurde einfach per Wiki-Definiton geklärt - und damit basta ;-). Es ist halt ein seperater Radweg in Gegenrichtung, der nicht seperat ist. ;-) (Ob jener Widerspruch am Anfang nicht bedacht wurde oder bereits bewußt in Kauf genommen wurde, weiß ich nicht.) (bicycle=opposite wäre ja auch eine Möglichkeit, aber diese einfache Möglichkeit hat wohl bereits mit 259:5190 verloren...) (Stand August 2009 OSMdoc) Die eleganteste (auch dokumentierte) Loesung ist: oneway:bicycle=no Gruß Georg ___ 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
[Talk-de] einfache OSM-XML Tools
Hallo, mit welchen Kommandozeilentools kann ich in .osm Dateien suchen und die Ergebnisse als ASCII ausgeben lassen? Vermutlich geht es mit jedem XML-Werkzeug, aber über ein paar OSM spezifische Beispiele würde ich mich freuen. Mfg Rudolf -- http://rettedeinefreiheit.de/ Gegen Freiheitsberaubung in Deutschland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplatz-Beschränkungen
Bernd Wurst schrieb: Hallo Burkhard. Am Montag 03 Mai 2010 13:44:56 schrieb bkmap: Wenn das P-Zeichen (Zeichen 314) nur mit den Zeichen 318 und 1040-30 steht, ist es nur in der angegebenen Zeit gültig. Das heißt Parken ist dann sowieso erlaubt, wenn es nicht aus einem anderen Grund verboten ist. Parken ist dann außerhalb dieser Zeiten verboten, wenn z.B. Zeichen 283 oder 286 für diese Straße gilt, oder es ist dort ein Zonenparkverbot (290.1) oder es ist eine Verkehrsberuhigte Zone (325.1) und die Parkflächen sind nicht markiert oder irgendein anderer Grund aus § 12 (1) oder (2). Das klingt nach gesammelter Kompetenz deinerseits, aber was willst du damit sagen? Mein Fahrlehrer (iirc) und der gesunde Menschenverstand sagen mir, wenn ich ein Konstrukt aus - Parkplatz (z314) - darunter nur mit Parkscheibe, z1040-32 - darunter die zeitliche Beschränkung, z1040-30 habe, dann gilt die zeitliche Einschränkung für die Parkscheibenpflicht bzw. die Höchstparkdauer. Ja, so habe ich mir das auch erst vorgestellt. Hab einen Fahrleher gefragt, der mir auch erst mal die gleiche Antwort gegeben hat. Sonst müssten die Schilder anders herum sein, da ein Zusatzzeichen sich immer auf das unmittelbar darüber befindliche Schild bezieht. Oder? Aber später meine er, dass in der Verwaltungsvorschrift zur STVO 44 (14.) ff steht, dass, wenn die Verkehrszeichen 224, 229, 245, 250, 251, 253, 255, 260, 261, 270.1, 274, 276, 277, 283, 286, 290.1, 314, 314.1 und 315 nur zu gewissen Zeiten gelten sollen, das mit einem Zusatzzeichen mit den Zeiten angezeigt werden kann. Also schränken die Zusatzzeichen nicht die Güligkeit eines anderen Zusatzzeichens ein, sondern die des Verkehrszeichens. (http://www.bundesrat.de/cln_171/nn_8336/SharedDocs/Drucksachen/2009/0101-200/154-09,templateId=raw,property=publicationFile.pdf/154-09.pdf) Daraus folgt, dass außerhalb der angegebenen Zeiten das darüber befindliche Verkehrszeichen (!!!nicht Zusatzzeichen!!!) nicht gültig ist. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] einfache OSM-XML Tools
Hallo, Rudolf Henze wrote: mit welchen Kommandozeilentools kann ich in .osm Dateien suchen und die Ergebnisse als ASCII ausgeben lassen? Ich weiss jetzt nicht genau, was Du mit als ASCII meinst. Fuer viele Sachen reicht schon der Standard-Unixbefehl grep (ggf. mit den Kommandozeilenoptionen -A10 und -B10 oder so); etwas besser auf OSM angepasst ist z.B. svn.openstreetmap.org/applications/utils/filter/osmgrep/osmgrep.pl. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplatz-Beschränkungen
Am Dienstag 04 Mai 2010 10:17:08 schrieb bkmap: Sonst müssten die Schilder anders herum sein, da ein Zusatzzeichen sich immer auf das unmittelbar darüber befindliche Schild bezieht. Oder? Aber später meine er, dass in der Verwaltungsvorschrift zur STVO 44 (14.) ff steht, dass, wenn die Verkehrszeichen 224, 229, 245, 250, 251, 253, 255, 260, 261, 270.1, 274, 276, 277, 283, 286, 290.1, 314, 314.1 und 315 nur zu gewissen Zeiten gelten sollen, das mit einem Zusatzzeichen mit den Zeiten angezeigt werden kann. Also schränken die Zusatzzeichen nicht die Güligkeit eines anderen Zusatzzeichens ein, sondern die des Verkehrszeichens. (http://www.bundesrat.de/cln_171/nn_8336/SharedDocs/Drucksachen/2009/0101-2 00/154-09,templateId=raw,property=publicationFile.pdf/154-09.pdf) Daraus folgt, dass außerhalb der angegebenen Zeiten das darüber befindliche Verkehrszeichen (!!!nicht Zusatzzeichen!!!) nicht gültig ist. Man könnte das so verstehen, ja. Ich glaube es allerdings nach wie vor nicht. Die VV sagt nichts darüber aus, wie es sich bei *mehreren* Zustazzeichen verhält. Es wird nur gesagt, dass z314 eines der Zeichen ist, die überhaupt per Zeitangabe beschränkt werden können. Also, gehen wir die Sache pragmatisch an: Klar, es gibt Flächen, da darf man nur zeitweise Parken. Da steht dann ein z314 und eine Uhrzeitangabe. Eindeutig. Ich kenne mehrere Stellen, an denen das ursprünglich genannte Konstrukt mit Parkscheibenpflicht und Uhrzeiten steht, und es ist definitiv so gemeint, dass man außerhalb der Zeiten frei parken darf. Die Angaben existieren auch schon seit deutlich vor der genannten VV. Lass es mich anders angehen: Deiner Meinung nach müsste z314 mit z1052-33 (nur mit Parkschein) und der Zeitangabe auch dazu führen, dass man da außerhalb der Zeiten nicht parken darf. Das ist definitiv nicht so. Unsere Stadtverwaltung macht nämlich explizit Werbung damit, dass man auf diesen Plätzen am Wochenende kostenlos parken darf. Und jeder mir bekannte Parkscheinautomat sagt mir deutlich, dass ich über Nacht parken darf wenn ich bis nach Ende der gebührenpflichtigen Zeit zahle. Gruß, Bernd -- Europa - das Ganze ist eine wunderbare Idee, aber das war der Kommunismus auch. - Loriot 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] Weitere Barrierentypen?
Am 3. Mai 2010 17:53 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Ich nutze die Barrieren recht häufig und mir ist aufgefallen, dass es noch ein paar häufig auftauchende davon gibt, für die bisher keine Werte vorgesehen sind. Das sind swing_gate für Kfz-Barrieren ähnlich Schranken, die zur Seite schwingen rope für Seile chain für Ketten Gibt es sprachlich eine Möglichkeit, rope und chain zusammen zu fassen? Es ist ja im Grunde der selbe Typ, nur ein anderes Material (es sei denn, du meinst etwas anderes als ich). Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ausdrucken von wanderkarten - kennt jemand etwas
Hallo, vieleicht kann es ja das Programm, daß ich gerade schreibe: gpx2map. Ursprüngliche Idee war aus GPX-Files einen Film zu erstellen. Das Resultat soll vergleichbar zu einem alten Programm von mir sein: http://www.dimitri-junker.de/html/map_eps2avi.html aber eben nicht per Handarbeit sondern praktisch vollautomatisch. Daneben kann es SlippyMaps aus den GPX-Files erzeugen, dazu wird ein mit: http://www.osmtools.de/easymap/index.php?lang=depage=editor erzeugtes html als Template verwendet. Und es kann die Karte auch als Bild speichern. Wenn ich Dich richtig verstehe willst Du kein GPX-File sondern eine Relation vorgeben um die dann die Karte erzeugt wird. Man könnte also entweder zuerst die Relation in ein GPX wandeln oder meinem Programm beibringen die Relation selber zu laden, sollte nicht so kompliziert sein. Wenn Du nur die reine Karte willst dürfte auch meine aktuelle Version von Taho.exe genügen. Damit kann man jetzt nicht nur Karten für GPS-Software laden (viele kleine Files (z.B. 1024*1024)) sondern auch das ganze Gebiet in ein Grafikfile (Einstellung size=free). Taho gibt es auf: http://www.dimitri-junker.de/html/openstreetmap.html das gpx2map kannst Du gerne als ß-Tester bekommen ;-) Ansonsten wird es wahrscheinlich in den nächsten Tagen sowieso rauskommen. Beides sind Windows- Programme, beide OpenSource (Visual C++) Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] einfache OSM-XML Tools
Am 4. Mai 2010 10:24 schrieb Frederik Ramm frede...@remote.org: Ich weiss jetzt nicht genau, was Du mit als ASCII meinst. Fuer viele ja, Du hast natürlich Recht, auch XML ist ASCII. Sachen reicht schon der Standard-Unixbefehl grep (ggf. mit den Kommandozeilenoptionen -A10 und -B10 oder so); etwas besser auf OSM -A etc. kenne ich, aber das ist dann wirklich sehr mühsam. angepasst ist z.B. svn.openstreetmap.org/applications/utils/filter/osmgrep/osmgrep.pl. jo, das ist ein prima Tool, das hilft mir weiter! Danke Rudolf -- http://rettedeinefreiheit.de/ Gegen Freiheitsberaubung in Deutschland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere Barrierentypen?
M∡rtin Koppenhoefer glaubte zu wissen: ich nutze die genannten auch schon, wollte aber mal nachfragen, ob es dazu Meinungen und Ergänzungen gibt. Diese würde ich sammeln und dann ggf. am Stück zur Abstimmung vorschlagen. Mir fällt gerade keine Ergänzung ein, ich würde aber vorschlagen, ein proposal zu schreiben, eine Weile zu warten und dann zur Abstimmung zu schreiten. Es dürften sich mit einiger Sicherheit noch andere melden, die hier nicht mitlesen. flo -- Tork ist afaik der Halsreif den die Kelten tragen und der ihren Status als freie Mitglieder der Gemeinschaft symbolisiert Ein Halsband, das Freiheit symbolisiert? Die spinnen, die Kelten ... [Daniel Brachmann und Martin Leidig in suse-talk] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte drucken (Photopapier)
Am 3. Mai 2010 14:49 schrieb Stephan Olbrich stephanolbr...@gmx.de: Eine einfache Lösung wäre mapgen.pl von Gary. (http://wiki.openstreetmap.org/wiki/Mapgen.pl) Das kann dir eine pdf erzeugen, die du dann Maßstabsgetreu mit beliebiger dpi drucken kannst. Wenn dir der Standardstil nicht zusagt, ich arbeite gerade an einem, der klassische topographische Karten imitiert: http://img709.imageshack.us/img709/8008/medinghoven.jpg Sieht super aus! Ist das auch irgendwie mit Höhenlinien und Schattierungen kombinierbar? Danke! :-) Höhenlinien gehen, wenn man sie mit Srtm2OSM (oder ähnlichen tools) erstellt, in die OSM-Daten mischt und dann Mapgen aufruft (soweit ich weiß arbeitet Gary in nächster Zeit an dieser Thematik). Die Kombination mit Schattierungen wollte ich demnächst einmal manuell mit inkscape versuchen, also das einbinden von passenden Kacheln, z.B. aus Kosmos, einer slippymap oder einem WMS-Dienst (das wäre wohl das beste). Momentan tappe ich bei der Umstellung auf die neueste Mapgen-Version noch etwas im dunkeln, aber sobald das geschafft ist, wollte ich damit anfangen und auch den ganzen Kram mal aufräumen und z.B. im Wiki veröffentlichen, damit jeder selbst Karten erstellen kann. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplatz-Beschränkungen
C. Brause glaubte zu wissen: Wer keine Lust hat Schildernummern rauszusuchen, versteht von dieser Antwort nicht sonderlich viel. :-( Eine deutliche Hilfe dabei ist http://de.wikipedia.org/wiki/Bildtafel_der_Verkehrszeichen_in_Deutschland flo -- Wie ich sagte: wenn Du Alan Cox heisst, kannst Du Deine Sourcen auch mit dem Bleistift auf Lochkarten markieren. [Karl-Heinz Zimmer in dcouln] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Dinge zusammenfügen OK?
Am 04.05.2010 08:13, schrieb Guenther Meyer: Am Dienstag 04 Mai 2010 00:55:13 schrieb AssetBurned: allerdings sehe ich schon ein problem bei der sache. OSM2Go als editor zeigt mir zum beispiel ein einzelnen node der als bank getaggt wurde als banken symbol an. wenn ich allerdings ein gebäude als bank tagge dann sehe ich erstmal nur ein gebäude. gut jetzt könnte man die frage aufwerfen, mappen wir für den renderer oder nicht? ich weiß ja nicht wie es mit anderen geräten ausschaut ob da auch diese probleme exsistieren. naja, einen punkt auszuwerten ist halt wesentlich einfacher, als sich den schwerpunkt einer flaeche rauszuziehen. selbst dann ist nicht sichergestellt, dass das icon oder die beschriftung auch auf dem gebaeude rauskommt, grade bei unfoermigen gebilden. Das sind doch alles schon längst gelöste Standardprobleme. Darauf sollten wir beim mappen wirklich keine Rücksicht mehr nehmen müssen. auch fuer router kann das hilfreich sein, um den nutzer bei einem groesseren gebaeude auf die richtige seite zu lotsen... Dafür gibt es barrier=entrance. In meinem Gebiet (Köln) setze ich im Umriss des Gebäudes am Hauseingang zudem einen Node mit den Adressinformationen. Dort, wo auch in der Realität die Hausnummer zu sehen ist, jeder ortsfremde Besucher also erstmal den (Haupt)Eingang suchen/vermuten wird. Ausnahmen können gelten für große Gebäude, z.B. Einkaufszentren, mit nur einer einzigen Hausnummer, aber vielen Eingängen. Hier kann es Sinn machen, die Adressinformation dem Gebäudeumriss hinzuzufügen und die einzelnen Eingänge mit barrier=entrace zu kennzeichnen. deshalb halte ich es durchaus fuer sinnvoll, den poi zusaetzlich als punkt mitten im gebaeude oder an einem anderen sinnvollen ort anzugeben (z.B. in der naehe des eingangs). optimal waere natuerlich noch eine art verknupfung (relation?) mit dem gebaeude, damit nicht zwei pois entstehen, wenn ein programm sowohl gebaeude als auch punkt auswertet. Ich halte das im allgemeinen für falsch, da so redundante Informationen gespeichert werden. Es gibt in dem Gebäude nur einen Supermarkt, nicht zwei. Raymond. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere Barrierentypen?
Hallo, bei uns wird auf einem Klinik-Gelände ein Geländer als Barriere eines Fußgängerplatzes zu einer Tramlinie eingesetzt, mein Bild dazu habe ich leider gerade nicht gefunden im osm wiki. Da es handrail=yes in Verbindung mit highway=steps gibt, wäre wohl barrier=handrail möglich. Nimm es bitte in die Liste auf, wenn Du ein Proposal machst. Grüße Dietmar -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org]im Auftrag von M?rtin Koppenhoefer Gesendet am: Montag, 3. Mai 2010 17:53 An: Openstreetmap allgemeines in Deutsch Betreff: [Talk-de] Weitere Barrierentypen? Ich nutze die Barrieren recht häufig und mir ist aufgefallen, dass es noch ein paar häufig auftauchende davon gibt, für die bisher keine Werte vorgesehen sind. Das sind swing_gate für Kfz-Barrieren ähnlich Schranken, die zur Seite schwingen rope für Seile chain für Ketten ich nutze die genannten auch schon, wollte aber mal nachfragen, ob es dazu Meinungen und Ergänzungen gibt. Diese würde ich sammeln und dann ggf. am Stück zur Abstimmung vorschlagen. Gruß 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 besseres Autorouting fuer Fahrradfaher erreichen. Ideen und Konstruktive Vorschlaege
Felix Hartmann schrieb: . . . Da ein Fahrradfahrer, Wanderer oder sagen wir Reiter jedoch mit der highway=* subjektiven Klassifizierung lange nicht soviel aussagen kann wie ein Autofahrer, fuer den dieses Modell zugeschnitten ist, und auch so gut funktioniert, dass es alltaeglich ist und man sich darunter in Zusammenhang mit Zusatztags ein sehr gutes Abbild bilden kann welches sehr gut fuer Autorouting umsetzbar ist. Fehlt dies fuer andere Transportmittel. Daher die Idee die ja nicht neu ist, fuer einen subjektiven Tag, in dem Fall fuer Fahrradfahrer. Es geht hier absolut nicht darum andere objektive Tags abzuwerten oder zu tauschen. Das Prinzip muss sein dass ein Standardsatz an Tags/Keys als Voraussetzung fuer Autorouting fuer Fahrradfahrer beachtet werden muss von jedem Autoroutingprogramm, aber zu feineren Differenzierung eben ein Schluessel benutzt werden kann, der Standardisiert ist, leicht verstaendlich, und von verschiedenen Routern umgesetzt wird, als Hilfe eingefuehrt wird. Ausserdem gehoert pro Transporttyp verstaendlich dokumentiert, welche Tags ausgewertet werden muessen (die Liste muss einerseits kurz sein, damit sie umsetzbar ist, andererseits aber alle populaeren Tracks mit Werten inkludieren) damit der class:bicycle Schluessel ausgewertet wird. Andererseits sollte es logisch aufgebaut sein. Stimmt. Ich bin absolut einverstanden mit der Anwendung von subjektiven Tags. Man sollte sich im Klaren sein, dass dies hier nicht nur ein neues Schema für Radfahrer ist, sondern ein Schema zur allgemeinen subjektiven Differenzierung von diversen Objekten sein kann. Es kann nicht nur Autoroutern wichtige Informationen geben, sondern auch anderen Anwendungen. Zum Routen von Wanderwegen sind meineserachtens die derzeit üblichen Informationen wie highway=*, sac_scale=*, trail_visibility=* und incline=* ebenfalls nicht aussagekräftig genug. class:hinking=* wäre analog zu class:bicycle=* anzuwenden. Ebenso könnte ich mir für die Beschreibung der Naturnähe class:nature=* vorstellen oder class.diving=* dafür, wie gut man ein Gewässer zum Tauchen einschätzt usw., usw. ... Auch würde class:bicycle=3 auch einem Hotel gut stehen, das top auf Radfahrer eingestellt ist und class:bicycle=-3 einem, das mit Radfahrern wenig zu tun haben will. Zu diesem subjektiven Schema gibt es so viele Anwendungen, wie man sich kaum träumen lassen kann. Ich würde so eine gute Idee nicht eingleisig an Autorouter für Fahrrad verschwenden. Dafür ist sie viel zu schade. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplatz-Beschränkungen
Bernd Wurst schrieb: Am Dienstag 04 Mai 2010 10:17:08 schrieb bkmap: Sonst müssten die Schilder anders herum sein, da ein Zusatzzeichen sich immer auf das unmittelbar darüber befindliche Schild bezieht. Oder? Aber später meine er, dass in der Verwaltungsvorschrift zur STVO 44 (14.) ff steht, dass, wenn die Verkehrszeichen 224, 229, 245, 250, 251, 253, 255, 260, 261, 270.1, 274, 276, 277, 283, 286, 290.1, 314, 314.1 und 315 nur zu gewissen Zeiten gelten sollen, das mit einem Zusatzzeichen mit den Zeiten angezeigt werden kann. Also schränken die Zusatzzeichen nicht die Güligkeit eines anderen Zusatzzeichens ein, sondern die des Verkehrszeichens. (http://www.bundesrat.de/cln_171/nn_8336/SharedDocs/Drucksachen/2009/0101-2 00/154-09,templateId=raw,property=publicationFile.pdf/154-09.pdf) Daraus folgt, dass außerhalb der angegebenen Zeiten das darüber befindliche Verkehrszeichen (!!!nicht Zusatzzeichen!!!) nicht gültig ist. Man könnte das so verstehen, ja. Ich glaube es allerdings nach wie vor nicht. Die VV sagt nichts darüber aus, wie es sich bei *mehreren* Zustazzeichen verhält. Es wird nur gesagt, dass z314 eines der Zeichen ist, die überhaupt per Zeitangabe beschränkt werden können. Also, gehen wir die Sache pragmatisch an: Klar, es gibt Flächen, da darf man nur zeitweise Parken. Da steht dann ein z314 und eine Uhrzeitangabe. Eindeutig. Ich kenne mehrere Stellen, an denen das ursprünglich genannte Konstrukt mit Parkscheibenpflicht und Uhrzeiten steht, und es ist definitiv so gemeint, dass man außerhalb der Zeiten frei parken darf. Die Angaben existieren auch schon seit deutlich vor der genannten VV. Lass es mich anders angehen: Deiner Meinung nach müsste z314 mit z1052-33 (nur mit Parkschein) und der Zeitangabe auch dazu führen, dass man da außerhalb der Zeiten nicht parken darf. Das ist definitiv nicht so. Falsch. Außerhalb der Zeiten kannst Du Dich so verhalten, als wäre das Schild gar nicht da. Wenn dann ohne dieses Schild Parken nicht verboten ist, kannst Du natürlich parken. Unsere Stadtverwaltung macht nämlich explizit Werbung damit, dass man auf diesen Plätzen am Wochenende kostenlos parken darf. Und jeder mir bekannte Parkscheinautomat sagt mir deutlich, dass ich über Nacht parken darf wenn ich bis nach Ende der gebührenpflichtigen Zeit zahle. Gruß, Bernd ___ 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 besseres Autorouting fuer Fahrradfaher erreichen. Ideen und Konstruktive Vorschlaege
Zu diesem subjektiven Schema gibt es so viele Anwendungen, wie man sich kaum träumen lassen kann. Ich würde so eine gute Idee nicht eingleisig an Autorouter für Fahrrad verschwenden. Dafür ist sie viel zu schade. Gruß Burkhard Das habe ich auch eindeutig so dokumentiert, und mit Absicht nicht bicycle:class, sondern class:bicycle gewaehlt. Das ist ja auch der Grund, warum viele so negativ eingestellt sind. Denn es geht hier nicht primaer um class:bicycle, sondern um das generelle ich will keine subjektiven Daten in OSM Thema. ___ 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] Parkplatz-Beschränkungen
Am Dienstag 04 Mai 2010 12:30:18 schrieb bkmap: Lass es mich anders angehen: Deiner Meinung nach müsste z314 mit z1052-33 (nur mit Parkschein) und der Zeitangabe auch dazu führen, dass man da außerhalb der Zeiten nicht parken darf. Das ist definitiv nicht so. Falsch. Außerhalb der Zeiten kannst Du Dich so verhalten, als wäre das Schild gar nicht da. Wenn dann ohne dieses Schild Parken nicht verboten ist, kannst Du natürlich parken. Dann muss man darüber streiten, ob auf einer rechteckigen Markierung innerhalb einer verkehrsberuhigten Zone jetzt geparkt werden darf oder nicht, wenn *kein* Parkplatzschild daneben steht. Aber da ich keine Lust auf die Diskussion habe, werde ich nichts weiter dazu schreiben, so lange mir nicht einer glaubhaft ein Beispiel nennen kann, wo das vom Schildaufsteller so gedacht ist, dass sich die Uhrzeit auf das Parken und nicht auf die Parkscheibe / den Parkschein bezieht. Hier bei mir vor Ort ist es definitiv anders gemeint. Warum diese Verwaltungsvorschrift von 2009 hier zur Klärung nicht hilft, habe ich ja schon geschrieben: Die definiert nur, welche Zeichen eine zeitliche Einschränkung überhaupt haben dürfen, nicht dass diese stets darauf bezogen sein muss. Gruß, Bernd -- Bart, kannst du mal kurz das Lenkrad halten, ich muss mich an 2 Stellen gleichzeitig kratzen! - Homer Simpson 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] Wie kann man besseres Autorouting fuer Fahrradfaher erreichen. Ideen und Konstruktive Vorschlaege
Felix Hartmann schrieb: Zu diesem subjektiven Schema gibt es so viele Anwendungen, wie man sich kaum träumen lassen kann. Ich würde so eine gute Idee nicht eingleisig an Autorouter für Fahrrad verschwenden. Dafür ist sie viel zu schade. Gruß Burkhard Das habe ich auch eindeutig so dokumentiert, und mit Absicht nicht bicycle:class, sondern class:bicycle gewaehlt. Das ist ja auch der Grund, warum viele so negativ eingestellt sind. Denn es geht hier nicht primaer um class:bicycle, sondern um das generelle ich will keine subjektiven Daten in OSM Thema. Wenn das so ist - ok. Mir schien es hier in der Diskussion schon ziemlich auf Fahrrad ausgerichtet. Übrigens würde ich dann Landschaft und Natur nicht in class:bicycle berücksichtigen (http://wiki.openstreetmap.org/wiki/Class:bicycle - Scenery and Nature). Diese Eigenschaften gehören den Fußgängern und Motorisierten genauso, wie den Radfahrern. Noch ein Argument für subjektive Daten: Ich kann mir nicht vorstellen, dass eine Eigenschaft wie Macht Spaß, dort Fahrrad zu fahren oder Ich fühle mich hier nicht wohl, so direkt an der Bundesstraße oder Die Landschaft ist hier herrlich oder Die Natur ist da fast unberührt usw. ohne subjektive Daten einigermaßen darzustellen. Man darf nicht vergessen dass der Anwender der Daten sehr subjektiv ist. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplatz-Beschränkungen
Bernd Wurst schrieb: Am Dienstag 04 Mai 2010 12:30:18 schrieb bkmap: Lass es mich anders angehen: Deiner Meinung nach müsste z314 mit z1052-33 (nur mit Parkschein) und der Zeitangabe auch dazu führen, dass man da außerhalb der Zeiten nicht parken darf. Das ist definitiv nicht so. Falsch. Außerhalb der Zeiten kannst Du Dich so verhalten, als wäre das Schild gar nicht da. Wenn dann ohne dieses Schild Parken nicht verboten ist, kannst Du natürlich parken. Dann muss man darüber streiten, ob auf einer rechteckigen Markierung innerhalb einer verkehrsberuhigten Zone jetzt geparkt werden darf oder nicht, wenn *kein* Parkplatzschild daneben steht. Aber da ich keine Lust auf die Diskussion habe, werde ich nichts weiter dazu schreiben, so lange mir nicht einer glaubhaft ein Beispiel nennen kann, wo das vom Schildaufsteller so gedacht ist, dass sich die Uhrzeit auf das Parken und nicht auf die Parkscheibe / den Parkschein bezieht. Hier bei mir vor Ort ist es definitiv anders gemeint. Warum diese Verwaltungsvorschrift von 2009 hier zur Klärung nicht hilft, habe ich ja schon geschrieben: Die definiert nur, welche Zeichen eine zeitliche Einschränkung überhaupt haben dürfen, nicht dass diese stets darauf bezogen sein muss. Hab auch keine Lust auf Polemik. Bringt ja auch nichts. Also Sense :-) Aber vielleicht lesen das mal ein paar Leute, die diese Wischiwaschi-Vorschriften verzapft haben :-) Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere Barrierentypen?
Am 4. Mai 2010 12:27 schrieb Dietmar ostr...@diesei.de: Da es handrail=yes in Verbindung mit highway=steps gibt, wäre wohl barrier=handrail möglich. das gälte dann auch für sowas hier, oder? http://www.adfc-bergstrasse.de/radverkehrsplanung/bilder-planung/rodau-radweg-anfang.jpg danke, das brauchen wir in der Tat, auch/vor allem auf (Barrieren-)ways. Bei Zäunen und Mauern (z.B.) finde ich auch die Höhe extrem wichtig. Schon eine 30cm Mauer ist eine Barriere für manche Verkehrsmittel, gesund und zu Fuß natürlich nicht. Ganz genau braucht man das auch gar nicht, besser eine geschätze Angabe, die auch mal 10-20cm daneben liegt, aber eine grobe Einschätzung erlaubt. Umlaufsperren (heisst das so? [1] ) mappe ich bisher immer als kissing_gate, ist aber wohl eigentlich (dem Namen nach) nur für doppelte Umlaufsperren gedacht? Gruß Martin [1] http://www.adfc-bergstrasse.de/radverkehrsplanung/bilder-planung/bahnquerung-lorsch.jpg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere Barrierentypen?
Auch Baumstämme fände ich für eine weitere Barriere sinnvoll. Man findet sie natürlich im Wald, aber auch im städtischen Umfeld und sie erfüllen oft eine Doppelfunktion: Absperrung und Sitzgelegenheit: http://www.pathfinder-project.de/crewtreffen/Mai%2007/img_6123.jpg http://home.arcor.de/timrenner/china/bilder/8trip2/heinan/01458.jpg das würde ich barrier=log nennen (idealerweise auch auf einem way, wenn es z.B. auch absturzsichernde Funktionen übernimmt, in den obigen Beispielen wäre wohl ein Node besser, ein Kreuzungsnode mit dem blockierten Way ist für den Fall, dass man doch einen Way für die Barriere nimmt wichtig.) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte drucken (Photopapier)
hi. thema höhenlinien: soweit ich das sehe ist mapgen reif dafür. will sagen, man benötigt eben nur die beigemischten höhendaten im osm file (osmosis) und eine neue regel im style file. oder sehe ich das falsch? mit schattierungen habe ich mich noch nicht beschäftigt. aber bei vorliegenden schattierungsbildern sollte es einfach sein, eine passende karte für obendrauf zu bauen. dann noch schnell ein grafikprogramm angeworfen, und los geht's. ciao gerhard - original Nachricht Betreff: Re: [Talk-de] Karte drucken (Photopapier) Gesendet: Di, 04. Mai 2010 Von: Martin Simongrenzde...@gmail.com Am 3. Mai 2010 14:49 schrieb Stephan Olbrich stephanolbr...@gmx.de: Eine einfache Lösung wäre mapgen.pl von Gary. (http://wiki.openstreetmap.org/wiki/Mapgen.pl) Das kann dir eine pdf erzeugen, die du dann Maßstabsgetreu mit beliebiger dpi drucken kannst. Wenn dir der Standardstil nicht zusagt, ich arbeite gerade an einem, der klassische topographische Karten imitiert: http://img709.imageshack.us/img709/8008/medinghoven.jpg Sieht super aus! Ist das auch irgendwie mit Höhenlinien und Schattierungen kombinierbar? Danke! :-) Höhenlinien gehen, wenn man sie mit Srtm2OSM (oder ähnlichen tools) erstellt, in die OSM-Daten mischt und dann Mapgen aufruft (soweit ich weiß arbeitet Gary in nächster Zeit an dieser Thematik). Die Kombination mit Schattierungen wollte ich demnächst einmal manuell mit inkscape versuchen, also das einbinden von passenden Kacheln, z.B. aus Kosmos, einer slippymap oder einem WMS-Dienst (das wäre wohl das beste). Momentan tappe ich bei der Umstellung auf die neueste Mapgen-Version noch etwas im dunkeln, aber sobald das geschafft ist, wollte ich damit anfangen und auch den ganzen Kram mal aufräumen und z.B. im Wiki veröffentlichen, damit jeder selbst Karten erstellen kann. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de --- original Nachricht Ende ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Dinge zusammenfügen OK?
Am 4. Mai 2010 12:10 schrieb Raimond Spekking raimond.spekk...@gmail.com: auch fuer router kann das hilfreich sein, um den nutzer bei einem groesseren gebaeude auf die richtige seite zu lotsen... Dafür gibt es barrier=entrance. im Wiki steht das anders. Dort wird barrier=entrance für Öffnungen in einer Barriere ohne weiteres Tor o.ä. definiert: If it is just a hole with no limitations on the way then tag it as: barrier=entrance. http://wiki.openstreetmap.org/wiki/Key:barrier Was Du meinst ist wohl building=entrance: http://wiki.openstreetmap.org/wiki/Tag:building%3Dentrance Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere Barrierentypen?
Am 4. Mai 2010 14:45 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 4. Mai 2010 12:27 schrieb Dietmar ostr...@diesei.de: Da es handrail=yes in Verbindung mit highway=steps gibt, wäre wohl barrier=handrail möglich. das gälte dann auch für sowas hier, oder? http://www.adfc-bergstrasse.de/radverkehrsplanung/bilder-planung/rodau-radweg-anfang.jpg Wenn du es als Node auf den Weg einträgst, sehe ich das als Fehler. Ansonsten ist es eher nur eine genauere Beschreibung des Zaunes (anstatt Latten ist da eine Metallstange) danke, das brauchen wir in der Tat, auch/vor allem auf (Barrieren-)ways. Bei Zäunen und Mauern (z.B.) finde ich auch die Höhe extrem wichtig. Schon eine 30cm Mauer ist eine Barriere für manche Verkehrsmittel, gesund und zu Fuß natürlich nicht. Ganz genau braucht man das auch gar nicht, besser eine geschätze Angabe, die auch mal 10-20cm daneben liegt, aber eine grobe Einschätzung erlaubt. Umlaufsperren (heisst das so? [1] ) mappe ich bisher immer als kissing_gate, ist aber wohl eigentlich (dem Namen nach) nur für doppelte Umlaufsperren gedacht? Gruß Martin [1] http://www.adfc-bergstrasse.de/radverkehrsplanung/bilder-planung/bahnquerung-lorsch.jpg http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dkissing_gate Klingt eher nach einem kleinen Tor. Für die Umlaufsperren solltest du cycle_barrier nehmen. http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcycle_barrier Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Dinge zusammenfügen OK?
Am 04.05.2010 14:56, schrieb M∡rtin Koppenhoefer: Am 4. Mai 2010 12:10 schrieb Raimond Spekking raimond.spekk...@gmail.com: auch fuer router kann das hilfreich sein, um den nutzer bei einem groesseren gebaeude auf die richtige seite zu lotsen... Dafür gibt es barrier=entrance. im Wiki steht das anders. Dort wird barrier=entrance für Öffnungen in einer Barriere ohne weiteres Tor o.ä. definiert: If it is just a hole with no limitations on the way then tag it as: barrier=entrance. http://wiki.openstreetmap.org/wiki/Key:barrier Was Du meinst ist wohl building=entrance: http://wiki.openstreetmap.org/wiki/Tag:building%3Dentrance Oh Schande... mein Fehler *schäm* Dann werde ich mich wohl mal ans umtaggen begeben. Danke für die Richtigstellung. Raymond. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere Barrierentypen?
Moin, André Riedel schrieb: http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dkissing_gate Klingt eher nach einem kleinen Tor. http://en.wikipedia.org/wiki/Kissing_gate zeigt das Prinzip etwas deutlicher. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte drucken (Photopapier)
mit schattierungen habe ich mich noch nicht beschäftigt. aber bei vorliegenden schattierungsbildern sollte es einfach sein, eine passende karte für obendrauf zu bauen. dann noch schnell ein grafikprogramm angeworfen, und los geht's. Ich hab das ganze mal mit osmarender versucht und bin daran gescheitert, dass SVG so in ein png zu wandeln, dass es eine definierte Fläche abbildet, ich also die Koordinaten der Ecken kenne. Ist das mit mapgen einfacher? Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie kann man besseres Autorouting fuer Fahrradfaher erreichen. Ideen und Konstruktive Vorschlaege
Felix Hartmann schrieb am 03.05.2010 21:40: Das Problem ist mehr, dass wir uns ueber Probleme die noch lange nicht auftauchen den Kopf zerbrechen. Sollte dies wirklich einmal so sein, dass edit wars um class:bicycle losgehen, kann man noch immer reagieren. Ich denke jedoch es ist so wie bei tracktype. Auch hier herscht kein Konsens, aber das vorhandensein der Daten die in 90% der Faelle passen, ist der Grund warum Autorouting in OSM ueberhaupt die kommerziellen Daten schlaegt. Der Unterschied dabei ist aber, dass tracktype zwar recht schwammig definiert aber immerhin ein objektives Tag sein soll. Bei einer subjektiven Bewertung sieht es doch ganz anders aus. Ein weiterer Punkt ist, dass bei der Wahl von geeigneten Wegen die Meinungen der Radfahrer doch sehr stark differenzieren, und das auch unabhaengig von irgendwelchen Kategorien: Die einen glauben, dass sie auf Radwegen sicher und bequem unterwegs sind, und die anderen wissen, dass Radwege langsam und gefaehrlich sind. Die Idee mit dem Mehrere-Meinungen-Sammeln beruht ja auch komplett auf den OSM-Erfahrungen. Ein einzelner, aufgezeichneter Track ist haeufig ganz schoener Schrott. Aber wenn man zehn Stueck davon hat, dann bekommt man auch unter schwierigen Bedingungen eine ganz ordentliche Spur. Aehnlich sieht es beim Routing aus: Alleine wenn wir wuessten, wo viele Mapper mit dem Rad langgefahren sind, dann koennten wir daraus schon schliessen, dass man da wahrscheinlich gut mit dem Rad langfahren kann. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte drucken (Photopapier)
yup, very easy. da gibt es einen parameter beim aufruf: -clipbbox=float,float,float,float (left, right, bottom, top of bbox for clipping map out of data - more precise than -clip; overrides -clip!) siehe manual. seite sieben. ciao gerhard On Tue, 2010-05-04 at 17:51 +0200, Stephan Olbrich wrote: mit schattierungen habe ich mich noch nicht beschäftigt. aber bei vorliegenden schattierungsbildern sollte es einfach sein, eine passende karte für obendrauf zu bauen. dann noch schnell ein grafikprogramm angeworfen, und los geht's. Ich hab das ganze mal mit osmarender versucht und bin daran gescheitert, dass SVG so in ein png zu wandeln, dass es eine definierte Fläche abbildet, ich also die Koordinaten der Ecken kenne. Ist das mit mapgen einfacher? Grüße, Stephan ___ 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] Weitere Barrierentypen?
2010/5/4 Georg Feddern ne...@bavarianmallet.de: Moin, André Riedel schrieb: http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dkissing_gate Klingt eher nach einem kleinen Tor. http://en.wikipedia.org/wiki/Kissing_gate zeigt das Prinzip etwas deutlicher. Das stimmt, habe das gleich mal im Wiki geändert. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie kann man besseres Autorouting fuer Fahrradfaher erreichen. Ideen und Konstruktive Vorschlaege
Die große Gefahr, die ich bei class:bicycle:... sehe, dass jeder Radfahrer anders denkt und anders eine Strecke einschätzt. Hinzu kommt, dass viele sich auch über die gesetzlichen Grundlagen nicht im klaren sind. Folge könnte sein, dass eine stark befahrene Straße ohen Radweg als gut bewertet wird, weil der mapper verbotenerweise immer auf dem Gehweg fährt. Weiterhin problematisch ist auch die Inhomogenität innerhalb der Gruppen. Daher würde ich eher andere Kriterien ansetzen. Bspw. Landschaft, Verkehrdichten pro Verkehrsart (motorisiert, Rad, Fußgänger). Ansonsten bekommt man offroad schon recht gut die Beschaffenheit der Wege ins routing integriert. Viele Grüße, aighes -- View this message in context: http://gis.638310.n2.nabble.com/Wie-kann-man-besseres-Autorouting-fuer-Fahrradfaher-erreichen-Ideen-und-Konstruktive-Vorschlaege-tp4997459p5004532.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Dinge zusammenfügen OK?
moin On 04.05.2010, at 08:13, Guenther Meyer wrote: Am Dienstag 04 Mai 2010 00:55:13 schrieb AssetBurned: allerdings sehe ich schon ein problem bei der sache. OSM2Go als editor zeigt mir zum beispiel ein einzelnen node der als bank getaggt wurde als banken symbol an. wenn ich allerdings ein gebäude als bank tagge dann sehe ich erstmal nur ein gebäude. gut jetzt könnte man die frage aufwerfen, mappen wir für den renderer oder nicht? ich weiß ja nicht wie es mit anderen geräten ausschaut ob da auch diese probleme exsistieren. naja, einen punkt auszuwerten ist halt wesentlich einfacher, als sich den schwerpunkt einer flaeche rauszuziehen. selbst dann ist nicht sichergestellt, dass das icon oder die beschriftung auch auf dem gebaeude rauskommt, grade bei unfoermigen gebilden. auch fuer router kann das hilfreich sein, um den nutzer bei einem groesseren gebaeude auf die richtige seite zu lotsen... deshalb halte ich es durchaus fuer sinnvoll, den poi zusaetzlich als punkt mitten im gebaeude oder an einem anderen sinnvollen ort anzugeben (z.B. in der naehe des eingangs). optimal waere natuerlich noch eine art verknupfung (relation?) mit dem gebaeude, damit nicht zwei pois entstehen, wenn ein programm sowohl gebaeude als auch punkt auswertet. darf ich mal fragen warum da gleich wieder mit relationen um sich geworfen wird? was spricht gegen einen weiteren node der einfach als eingang=ja getaggt wird? gut ist deutsch aber es geht ja um die idee. ich meine wenn man ne straße mappt die von einem zaun gekreuzt wird und an der kreuzungsstelle eine schranke oder so ist, macht man ja auch keine relation aus straße, zaun und nen node der schranke=ja heißt oder so. allen die das beschriebene problem mal durchgetestet haben, ein herzliches Danke! ich pack das mal als bug in den entsprechenden tracs :-) cu assetburned 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] Weitere Barrierentypen?
Am 4. Mai 2010 15:07 schrieb André Riedel riedel.an...@gmail.com: http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dkissing_gate Klingt eher nach einem kleinen Tor. ja, dem Bild nach handelt es sich um einen speziellen Typ von Vereinzelungsanlagen. Für Vereinzelungsanlagen könnte man auch noch was generelles brauchen (Drehkreuze halbhoch (wie im Supermarkt) und hoch (wie z.B. bei Industriegelände oder Stadien, Drehsperren (3 Holme die sich um die Horizontale drehen), Zusätze z.B. mit RFID, Magnetleser, Zifferneingabe, Biometrie, surveillance, ... ). Kissing gates wären dann theoretisch ein Teil davon (praktisch wird man ihnen vielleicht den eigenen Tag lassen). Für die Umlaufsperren solltest du cycle_barrier nehmen. http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcycle_barrier Danke, sowas suchte ich. Da wäre auch ein Zusatztag nicht schlecht, ob es mehrere hintereinander sind oder nur eine Verengung. Oder man taggt die Verengung wie auf dem einen Beispielbild als Poller (idealerweise noch mit maxwidth). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte drucken (Photopapier)
Martin Simon grenzdebil at gmail.com writes: Wenn dir der Standardstil nicht zusagt, ich arbeite gerade an einem, der klassische topographische Karten imitiert: http://img709.imageshack.us/img709/8008/medinghoven.jpg Das sieht richtig gut aus. Wäre an der Rules-Datei interessiert. Volker ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere Barrierentypen?
M∡rtin Koppenhoefer dieterdre...@gmail.com [Mon, May 03, 2010 at 05:53:06PM CEST]: Ich nutze die Barrieren recht häufig und mir ist aufgefallen, dass es noch ein paar häufig auftauchende davon gibt, für die bisher keine Werte vorgesehen sind. Im Wald bemerke ich häufig MTB-Vergrämungsmaßnahmen, die aus improvisierten Materialien gefertigt sind: barrier=log habe ich schon einmal eingetragen barrier=heap wäre auch manchmal angebracht -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte drucken (Photopapier)
Gary G: gary at gary68.de writes: hi. thema höhenlinien: soweit ich das sehe ist mapgen reif dafür. will sagen, man benötigt eben nur die beigemischten höhendaten im osm file (osmosis) und eine neue regel im style file. oder sehe ich das falsch? Für eine Karte mit Höhenlinien habe ich mir ein script gebastelt (nicht lachen, sieht unprofessioniell aus, aber funktioniert ;) ) ==snip #!/bin/bash mono /speicher/garmin/srtm2osm/Srtm2Osm.exe -large -bounds1 49.61 8.91 49.755 9.155 -step 10 osmosis --read-xml-0.5 enableDateParsing=no srtm.osm --migrate --wx srtm6.osm wget http://api.openstreetmap.org/api/0.6/map?bbox=8.91,49.61,9.155,49.75 -O osm-michelstadt.osm osmosis --read-xml-0.6 file=osm-michelstadt.osm --sort-0.6 --read-xml-0.6 file=srtm6.osm --sort-0.6 --merge --write-xml-0.6 file=data-srtm-michelstadt.osm nice perl mapgen.pl -in=data-srtm-michelstadt.osm -ppc=6.5 -style=mapgenRules.csv -out=Mi25000.svg -pdf -grid=20 -scaleset=25000 -clipbbox=8.91,9.155,49.61,49.755 -scale acroread Mi25000.pdf =snap= Das script lädt die Höhendaten herunter, bereitet sie für mapgen auf und gibt sie mir als svg und als pdf aus. PDF wird anschließend mit dem Acrobat-Reader angezeigt. Das ganze hab ich mir unter Linux (Debian) eingerichtet. Für die Höhenlinien (alle 10 Meter) hab ich folgende Regel unter SECTION WAYS in die mapgenRules.csv eingefügt: ==snip contour elevation orange 1 5 none 0 0 none black 10 sans-serif 0 1 0 none 0 5 ==snap Bin da noch heftig am Basteln. Vorschläge für Verbesserungen werden gerne angenommen. Volker ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Dinge zusammenfügen OK?
Am Dienstag 04 Mai 2010 12:10:47 schrieb Raimond Spekking: Am 04.05.2010 08:13, schrieb Guenther Meyer: Am Dienstag 04 Mai 2010 00:55:13 schrieb AssetBurned: allerdings sehe ich schon ein problem bei der sache. OSM2Go als editor zeigt mir zum beispiel ein einzelnen node der als bank getaggt wurde als banken symbol an. wenn ich allerdings ein gebäude als bank tagge dann sehe ich erstmal nur ein gebäude. gut jetzt könnte man die frage aufwerfen, mappen wir für den renderer oder nicht? ich weiß ja nicht wie es mit anderen geräten ausschaut ob da auch diese probleme exsistieren. naja, einen punkt auszuwerten ist halt wesentlich einfacher, als sich den schwerpunkt einer flaeche rauszuziehen. selbst dann ist nicht sichergestellt, dass das icon oder die beschriftung auch auf dem gebaeude rauskommt, grade bei unfoermigen gebilden. Das sind doch alles schon längst gelöste Standardprobleme. Darauf sollten wir beim mappen wirklich keine Rücksicht mehr nehmen müssen. so? und wie? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Dinge zusammenfügen OK?
Am 4. Mai 2010 12:10 schrieb Raimond Spekking raimond.spekk...@gmail.com: Ausnahmen können gelten für große Gebäude, z.B. Einkaufszentren, mit nur einer einzigen Hausnummer, aber vielen Eingängen. Hier kann es Sinn machen, die Adressinformation dem Gebäudeumriss hinzuzufügen und die einzelnen Eingänge mit barrier=entrace zu kennzeichnen. Meine Erachtens ergibt es *immer* Sinn, den Eingang als Eingang (barrier/building=entrance) und die Adressinformation an das große Ganze zu taggen. (das kann später durchaus auch das Grundstück sein, wenn wir diese Information mal haben) addr:housenumber heißt ja nicht an dieser Stelle ist eine lustige Nummer angepinselt sondern diesem Objekt ist folgende Hausnummer zugehörig. ;-) Gruß aus der Nachbarschaft, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere Barrierentypen?
Am 4. Mai 2010 21:50 schrieb Johannes Huesing johan...@huesing.name: Im Wald bemerke ich häufig MTB-Vergrämungsmaßnahmen, die aus improvisierten Materialien gefertigt sind: barrier=log habe ich schon einmal eingetragen barrier=heap wäre auch manchmal angebracht Du könntest gleich die örtliche Notarzt-Rufnummer dazutaggen - wobei ich jetzt nicht beurteilen will, ob das eher dem Verhalten des Försters oder der Fahrweise des typischen Mountainbikers zu schulden ist... ;-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Dinge zusammenfügen OK?
Am 5. Mai 2010 01:47 schrieb Martin Simon grenzde...@gmail.com: addr:housenumber heißt ja nicht an dieser Stelle ist eine lustige Nummer angepinselt sondern diesem Objekt ist folgende Hausnummer zugehörig. ;-) verschiedene Eingänge sollen verschiedene Nummern bekommen, und teilweise haben Eckhäuser auch Nummern an beiden Straßen, von daher lehne ich das Taggen von Hausnummern an Eingängen nicht komplett ab. Andererseits ist das Grundstück ausschlaggebend für die Nummer (es sind in Berlin z.B. Grundstücksnummern). Eigentlich hätte ich gerne Grundstücke (als relation) bzw. sites (1), die die Adress-information erhalten, und alle Gebäude, POIs, etc. werden dann ebenfalls diesem Grundstück zugewiesen. (1) mit sites meine ich hier zusammengehörige Anlagen. Diese können auch mehrere Grundstücke enthalten, und da echte Grundstücksgrenzen ja bekanntermaßen rar sind, und eine Aufteilung in echte Grundstücke für OSM-Zwecke sowieso erstmal keinen großen Nutzen verspricht, würde ich die als Einheit verstehen. Einzelne Grundstücke könnte man ebenfalls mit den site-Relationen machen. Zu den sites gibt es schon seit über 2 Jahren ein Proposal, das aber nicht so richtig vorankommt: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site wollen wir das mal ein bisschen pushen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neuer Nutzer von OSM
In seinem Newsletter vom 5.4. hat Vesseltracker bekanntgegeben: -- Zitat -- Editorial Wir haben die Karten neu gemischt Unserer wichtigste Nachricht: Wir verwenden ab sofort für unsere Karten OpenStreetMap. Diese Karte ist präzise und die weltweite Wiki-Community kann jederzeit Detailverbesserungen anbringen. Die Geschmäcker sind verschieden, aber uns gefallen das klare Layout der Karten und die Flexibilität, die uns ständige Anpassungen und Verbesserungen ermöglicht. Es ergeben sich kleinere Änderungen bei der Benutzung, die wir unter Tipps Tricks erklären. Die vesseltracker.com Pages etablieren sich mehr und mehr als Informationsquelle für hafen- und schiffsbezogene Dienstleitungen. Fast 2.000 Unternehmen sind bereits registriert und können komfortabel gefunden werden. Weiter unten steht wie das geht und was es bringt. Neben der neuen Karten gibt es noch zahlreiche weitere kleinere Neuerungen. Stöbern Sie mal selbst bei vesseltracker.com oder lesen Sie im Blog[1] über Neuigkeiten Ihr vesseltracker.com-Team [1] http://blog.vesseltracker.com/ Gruss Michael Schmitt ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSMWMS der IT-Consult auf D-A-CH-Staaten erweitert
Hallo Liste - Zur Info: IT-Consult erweitert OSM-WMS auf die D-A-CH-Staaten Pünktlich zum 1. Mai 2010 hat die hallesche Stadtwerketochter IT-Consult ihren WMS mit OpenStreetMap-Daten neben der deutschlandweiten Verfügbarkeit um die Staaten Österreich und Schweiz erweitert. Damit ist ein oft geäußerter Nutzerwunsch wahr geworden und alle D-A-CH-Staaten sind komplett über den OSMWMS in gewohnter Qualität verfügbar. Es stehen weiterhin acht verschiedene, einzeln zuschaltbare Layer, eine Grau- und eine Farbversion sowie viele gebräuchliche Projektionen zur Verfügung. Der Dienst wird wie bisher täglich direkt vom Planet.OSM aktualisiert. Auch in Zukunft plant die ITC, den Ausschnitt des Dienstes stetig um weitere Staaten zu ergänzen, so beispielsweise im Sommer 2010 um Frankreich und die Benelux-Staaten. Der ITC-OSMWMS steht der Internet-Gemeinde für die private Nutzung kostenfrei zur Verfügung, die nichtprivate Nutzung inkl. hochaufgelöstem Druckdienst, kundenspezifischer Präsentation und weiterer Extras ist kostenpflichtig. Kontakt:osm...@itc-halle.de Web:http://osmwms.itc-halle.de und http://www.osmwms.de mikeE. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
