Re: [Talk-de] Karte mit Restriktionen
Tobias Knerr schrieb: > > Möchte nur darauf hinweisen, dass solche Einschränkungen an Nodes nicht > gerade üblich sind (90 % der Vorkommen sind an Ways), im Wiki nicht als > mögliche Verwendung dokumentiert sind und die Verarbeitung beim Routing > erschweren. Dafür jetzt als "Belohnung" schöne Verkehrszeichen zu malen, > während die übliche und m.E. sinnvolle Variante am Way leer ausgeht... naja. Danke für den Hinweis. Es war auch mein Ziel diese Einschränkungen auch auf Wegen entsprechend darzustellen. Für Nodes war es aber auf die Schnelle einfacher dies sinnvoll zu implementieren. Ich werde versuchen die Karte nach und nach zu erweitern/verbessern, auch wenn sie aufgrund ihres geringen Umfangs (der leider nicht beliebig ausbaubar ist) nur als Demo taugt. Ganz außer Acht lassen will ich die Nodes allerdings nicht, da es doch einige Fälle gibt in denen sie meiner Meinung nach "richtiger" sind als eine Einschränkung auf Wegen. (z.B. bei einem Tor, sowohl als Stadttor-Variante als auch eines in einem Gatter). Frederik F. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte mit Restriktionen
Ulf Lamping schrieb: > Hast du vielleicht eine Liste was du genau jeweils wie anzeigst? Sowas > wie ne Legende oder zumindest das (möglichst gekürzte) Stylesheet? maxspeed (way): <20 rote dünne Linie 20 - 30 dunkelorange dünne Linie 30 - 60 hellorange dünne linie 60 - 80 gelbe dünne dünne linie + generell Geschwindigkeitsbeschränkung als Text überhalb der Linie maxheight (node): symbol verkehrszeichen 265 mit beschriftung maxwidth (node): symbol verkehrszeichen 264 mit beschriftung (wenn sowohl maxheight als auch maxwidth gesetzt sind, dann beide Symbole nebeneinander) maxweight (way): rote Beschriftung (unterhalb der Geschwindigkeitslinie wenn vorhanden) access: private/nohalbtransparente gestrichelte rote dicke linie destination halbtransparente gestrichelte blaue dicke linie permissivehalbtransparente gestrichelte grüne dicke linie (bei track und path kann die rote linie auch motorcar=no bedeuten) soweit der derzeitige Stand. Gruß Frederik F. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karte mit Restriktionen
Hallo, für Interessierte befindet sich unter http://osm.studio-24.net/map/ eine kleine Demokarte, die diverse Restriktionen etwas in den Vordergrund stellt. (maxspeed, maxweight, maxheight, access) Das abgedeckte Gebiet umfasst den Großteil des Münchner Stadtgebietes und ist in den Zoomstufen 14-16 verfügbar, wobei Zoom 14 bislang nur der Übersicht dient. Anmerkungen: * Die Regeln für die maxweight-Restriktionen waren leider fehlerhaft, deshalb steht an den entsprechenden Stellen im Moment nur "maxweight" anstatt des max. Gewichts. * An manchen Stellen sind Ortsnamen o.a. abgeschnitten, was daran liegt, dass jede Kachel aus ihrem entsprechenden Zoom-14-Kachel-Datensatz gerendert wurde und deshalb umliegende Nodes nicht beachtet wurden. Viele Grüße Frederik F. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Heiko Jacobs schrieb: > Ja, sowas waere noetig fuer einseitiges... > >> ( http://osm.studio-24.net/images/cobra/dev08091603.jpg ) > > Die DIskussionsseite klingt so, als waere das getrickst, oder > verstehe ich da was falsch? Getrickst ist da nichts. Nur die Straßenbegleitenden Fußwege im oberen Bildbereich sind (als Vergleichsmöglichkeit bzw. Workaround für Mapnik/Osmarender) als reale Daten existent. Deshalb dort auch die etwas "komische" Darstellung. > ABer vermutlich meinst Du das, was auf der Cobra-Seite mit > virtual ways bezeichnet wurde und das mit dem dy=0.4? > Macht Cobra aus dem .osm dann trotzdem gueltiges SVG? Virtual Ways sind ein völlig anderes Konzept (es geht hier um eine möglichst optimale Konkatenation und Wiederaufteilung von beschrifteten Straßen in einem Vorverarbeitungsschritt, um auch ohne Änderungen am eigentlichen Text-Positionierungs-Algorithmus eine Garantie für Nichtüberschneidungen und angemessener Häufigkeit der Wiederholung zu erhalten.), das aber aufgrund unschöner Seiteneffekte beim Tilerendering in der nächsten Version durch ein anderes Konzept ersetzt werden wird. Das SVG ist gültig. Alle logisch erstellten Daten werden genauso ausgegeben, als würden sie realen Daten entstammen. Viele Grüße Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Dimitri Junker schrieb: > Hallo, > >> Wie schon erwähnt wurde, ist Cobra in der Lage mit Offsets umzugehen, > > Cobra hab ich ja noch nie gehört, und die deutsche Wikipedia weis dazu auch > nur, daß es eine Programiersprache ist. Ging es nicht noch exotischer? Aber > egal, was meinst Du mit Offset? Eine einfache Translation reicht ja nicht. > > Dimitri http://wiki.openstreetmap.org/index.php/Cobra Dieses Cobra meinte ich. Mit Offset meine ich eine "Projektion" des Pfades um einen bestimmten Betrag nach rechts oder links. Eine einfache Translation würde ja, wie von dir erwähnt, nicht ausreichen. ( http://osm.studio-24.net/images/cobra/path_offset.png ) ( http://osm.studio-24.net/images/cobra/dev08091603.jpg ) Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Heiko Jacobs schrieb: > SVG kann das offenbar nicht loesen... > Gibt es andere Moeglichkeiten, parallel verschobene Linien zu > erzeugen irgendwo im Prozess zwischen OSM-Daten auslesen und > SVG erzeugen in Osmarender (und Mapnik irgendwann auch)? > Vielleicht ein geometrischer Vorprozessor zwischen API und Renderern? SVG an sich hat kein Pfad-Attribut für Offsets, das ist richtig. Allerdings wäre es kein allzu großer Aufwand eine entsprechende Funktion in den Osmarender zu integrieren, sofern man sich an die ORP Variante hält. In welchem Umfang im Moment noch die ältere XSLT Variante in Betrieb ist kann ich allerdings nicht sagen. Das Mapnik keine Unterstützung dafür hat ist für mich etwas verwunderlich. Wie schon erwähnt wurde, ist Cobra in der Lage mit Offsets umzugehen, wobei dies in der Momentan vorliegenden Version auch nur im Rastergrafik-Modus funktioniert. Soweit ich gehört habe soll sich das im nächsten Release auch auf die SVG Ausgabe auswirken. Andererseits ist Cobra im Moment noch nicht so Recht für den produktiven Einsatz zu empfehlen. Frederik Fischer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NEUGIER
Wälder und Riverbanks lohnen also doch. Güße aus der TOP3 Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karlsruhe Schema => volle Infos?
Florian Lohoff schrieb: > Ist im prinzip ja die associatedStreet relation nur das mehr als ein > way member drin ist. Als ich mit der associatedStreet rumgespielt habe > ist mir das thema multiple way members schon aufgefallen. Ist nen > bischen doof das da nur ein member geht wenn oftmals ist der weg ja in > minischnipsel zerschnitten wegen oneway, maxspeed oder sonstwelchen > aenderungen. Auch wenn es postalisch/namenstechnisch der selbe weg ist. > > Find ich auch super wenn sich sowas durchsetzen wuerde alleine wegen der > tonnen an redundanten daten. Jetzt mit den paar addressen in der > datenbank ist das ja alles easy - aber wenn jedes haus erstmal eine > addresse hat > > Flo > Die Einschränkung bezüglich der Anzahl der Way-Members ist mir auch schon lange ein Dorn im Auge und mappe deswegen konsequent gegen diese Regel. Es mag zwar einen geringen Vorteil bei der Suche nach dem korrekten Straßensegments bezüglich eines addr:housenumber Nodes bringen aber gleichzeitig eine Menge an gleichartigen/gleichnamigen Relationen für jedes Teilstück der Straße implizieren, was für mich ein unverantwortliches Vorgehen wäre. Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cobra Wunschliste
Christian schrieb: > Hi, > hier meine Wünsche : > > 1) Statt "Canel" bitte "Cancel" in die Boxen schreiben > öha > 2) Möglichkeit, bestehende Projekte editieren zu können > bei der GUI bin ich mir noch nicht sicher ob die in irgendeiner Form produktiv ist. Die aktuelle GUI ist zum Großteil nach meinem eigenen Bedürfnis entworfen: sprich immer wieder die selben Einstellungen auf den selben Daten laufen lassen zu können. Aber abgesehen davon, wird die Option noch eingebaut, da eine brauchbare GUI warten muss, bis meine Wunschliste beim Renderer abgearbeitet ist. > 3) Bequemere Koordinateneingabe bei Render Region, zB > ähnlich wie bei JOSM durch einfügen eines Permalinks > ok > 4) Möglichkeit, einen GPX-Track in die Karte einzurendern > ok. > Dank+Gruß > Christian > Gruß Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cobra Renderer 0.2.9
Lorenz Lang schrieb: > Frederik Fischer schrieb: > > >> Da war ich wohl ein bisschen zu optimistisch. Leider wird der >> ursprüngliche Fehler in der Commandline-Version nicht angezeigt. Ich >> werde später (oder morgen) mal eine Testversion schreiben, die da >> genauere Details bringt. Eigentlich dachte ich, die Laufzeitkompilierung >> würde in Mono bereits funktionieren. >> >> An die GUI-Tester: Wenn ein Fehler angezeigt wird, sollte man nach durch >> die Tastenkombi Strg-D (ggfls davor in den Text klicken) den Button >> "Details" sichtbar machen können. Dort sollten dann genauere Infos >> angezeigt werden. >> > > Habe jetzt aus Neugier obs an der Mono-Version liegt die aktuelle > Version 1.9.1 aus Sourcen für meinen AMD_64 Ubuntu Hardy kompiliert > So wies ausschaut geben sowohl die Paketversion 1.2.6 und die > kompilierte 1.9.1 dieselbe Fehlermeldung. > > Wenns ne neue Testversion gibt, Mail an mich, dann probier ich das gerne > aus. > > Bei der GUI-Version kriege ich folgende Fehler mit ctrl-d sichtbar: > > > Precompilation of rule filters failed. > > -- > > osm.rendering.configuration > > -- > > at > OSM.Rendering.Configuration.RuleFilterCompiler.CompileRuleFilterMethods > (System.String rulesDocumentFilename, System.String ruleFilterMethods) > [0x0] > > at OSM.Rendering.Configuration.Cobra.CobraRuleDocument.Read > (System.String ruleFilename) [0x0] > > at OSM.Rendering.Cobra.DocumentRenderHandler.GetRuleDocument () [0x0] > > at OSM.Rendering.Cobra.DocumentRenderHandler.Run () [0x0] > > Inner Exception: > > > > > > ApplicationName='gmcs', CommandLine='/target:library /debug- /optimize+ > /warn:3 /out:"/tmp/4c9b48c5/5322cd58.dll" /r:"System.dll" > /r:"osm.dom.dll" /r:"mscorlib.dll" -- "/tmp/4c9b48c5/5322cd58.0.cs" ', > CurrentDirectory='' > > -- > > System > > -- > > at System.Diagnostics.Process.Start_noshell > (System.Diagnostics.ProcessStartInfo startInfo, > System.Diagnostics.Process process) [0x0] > > at System.Diagnostics.Process.Start_common > (System.Diagnostics.ProcessStartInfo startInfo, > System.Diagnostics.Process process) [0x0] > > at System.Diagnostics.Process.Start () [0x0] > > at (wrapper remoting-invoke-with-check) > System.Diagnostics.Process:Start () > > at Mono.CSharp.CSharpCodeCompiler.CompileFromFileBatch > (System.CodeDom.Compiler.CompilerParameters options, System.String[] > fileNames) [0x0] > > at Mono.CSharp.CSharpCodeCompiler.CompileFromSourceBatch > (System.CodeDom.Compiler.CompilerParameters options, System.String[] > sources) [0x0] > > at Mono.CSharp.CSharpCodeCompiler.CompileAssemblyFromSourceBatch > (System.CodeDom.Compiler.CompilerParameters options, System.String[] > sources) [0x0] > > at System.CodeDom.Compiler.CodeDomProvider.CompileAssemblyFromSource > (System.CodeDom.Compiler.CompilerParameters options, System.String[] > fileNames) [0x0] > > at > OSM.Rendering.Configuration.RuleFilterCompiler.CompileRuleFilterMethods > (System.String rulesDocumentFilename, System.String ruleFilterMethods) > [0x0] > > > Auf der Kommandozeile: > > [EMAIL PROTECTED]:~/bin/mono/mono-1.9.1$ mono > ~/bin/cobra/osm.rendering.console.exe -d > "/home/lorenz/bin/cobra/data.osm" -o "." -w 1024 -r > "/home/lorenz/bin/cobra/cobra.rules-z17.xml" > ===Error= > Aborted Rendering. > ===Description=== > Cannot interprete rendering rules. Please check for syntactical erros in > rule conditions. > > ===Message=== > Precompilation of rule filters failed. > ===Source > osm.rendering.configuration > ===StackTrace > at > OSM.Rendering.Configuration.RuleFilterCompiler.CompileRuleFilterMethods > (System.String rulesDocumentFilename, System.String ruleFilterMethods) > [0x0] > at OSM.Rendering.Configuration.Cobra.CobraRuleDocument.Read > (System.String ruleFilename) [0x0] > at OSM.Rendering.Cobra.DocumentRenderHandler.GetRuleDocument () [0x0] > at OSM.Rendering.Cobra.DocumentRenderHandler.Run () [0x0] > = > > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > > > Danke. Das schaut so aus als hätte da der C# Compiler ein paar Probleme. (Die Regeln werden vor dem Rendern in Code übersetzt und nativ die Anwendung kompiliert) Eventuell sollte ich mir doch auch mal eine Mono-Testumgebung einrichten. Ich werde mich da mal weiter informieren wo genau das Problem zu sein scheint. Gruß, Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cobra Renderer 0.2.9
Lorenz Lang schrieb: > Sorry für die sich überschneidenden Posts. > > Frederik Fischer schrieb: > >> viele Dank für eure Mühe. Im Prinzip würde es reichen wenn irgendein >> relevanter Datenausschnitt (z.b: http://www.studio-24.net/osm/data.osm ) >> ohne Fehler gerendert würde. Ob aus der GUI oder per Console ist egal. >> Letzteres sollte einfach permono osm.rendering.console.exe -d >> "./data.osm" -o "." -w 1024 -r "./cobra.rules-z17.xml" gehen. >> > > $ mono osm.rendering.console.exe -d "./data.osm" -o "." -w 1024 -r > "./cobra.rules-z17.xml" > ===Error= > Aborted Rendering. > ===Description=== > Cannot interprete rendering rules. Please check for syntactical erros in > rule conditions. > > ===Message=== > Precompilation of rule filters failed. > ===Source > osm.rendering.configuration > ===StackTrace > at > OSM.Rendering.Configuration.RuleFilterCompiler.CompileRuleFilterMethods > (System.String rulesDocumentFilename, System.String ruleFilterMethods) > [0x0] > at OSM.Rendering.Configuration.Cobra.CobraRuleDocument.Read > (System.String ruleFilename) [0x0] > at OSM.Rendering.Cobra.DocumentRenderHandler.GetRuleDocument () [0x0] > at OSM.Rendering.Cobra.DocumentRenderHandler.Run () [0x0] > = > > > Mit absoluten Pfaden bei den Dateien selbes Ergebnis. > > So wie ich das jetzt lese knallts in der Funktion, die das Regel-XML > einliesst. (Ich programmiere eher mit Java und nicht mit .net, deswegen > keine Garantie auf diese Aussage :-) > > Grüße. > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > Da war ich wohl ein bisschen zu optimistisch. Leider wird der ursprüngliche Fehler in der Commandline-Version nicht angezeigt. Ich werde später (oder morgen) mal eine Testversion schreiben, die da genauere Details bringt. Eigentlich dachte ich, die Laufzeitkompilierung würde in Mono bereits funktionieren. An die GUI-Tester: Wenn ein Fehler angezeigt wird, sollte man nach durch die Tastenkombi Strg-D (ggfls davor in den Text klicken) den Button "Details" sichtbar machen können. Dort sollten dann genauere Infos angezeigt werden. Gruß, Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cobra Renderer 0.2.9
Lorenz Lang schrieb: > > (...) > Das liegt nur dran, dass unter Ubuntu die System.Windows.Forms nicht per > Default installiert werden. Installiert man das Paket > "libmono-winforms2.0-cil" und die davon abhängigen Pakete nach, lässt > sich das Programm problemfrei starten. > > Habe das jetzt mit Ubuntu 8.04 Hardy Heron getestet. Weiß jetzt nicht ob > die Mono-Versionen in älteren Ubuntu Varianten das auch packen. Die > Hardy Mono-Version 1.2.6 tut jedenfalls. > > Wenn ich bestimmte Tests machen soll, dann bitte einfach mailen! > > Gruß, Lorenz > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > Hallo, viele Dank für eure Mühe. Im Prinzip würde es reichen wenn irgendein relevanter Datenausschnitt (z.b: http://www.studio-24.net/osm/data.osm ) ohne Fehler gerendert würde. Ob aus der GUI oder per Console ist egal. Letzteres sollte einfach permono osm.rendering.console.exe -d "./data.osm" -o "." -w 1024 -r "./cobra.rules-z17.xml" gehen. Gruß, Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cobra Renderer 0.2.9
Nach einer kurzen Pause (zumindest was den Release neuer Versionen angeht) ist nun eine neue Version verfügbar. Zu finden unter http://wiki.openstreetmap.org/index.php/Cobra oder wie gehabt. Da nun alle externen Referenzen entfernt sind, besteht eine reelle Chance, dass diese Version ohne Einschränkungen unter Linux/Mono ausführbar ist. (Sollte jemand beschließen diese Aussage zu überprüfen und mir das Ergebnis mitzuteilen, wäre ich jenem äußerst dankbar.) viele Grüße Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hierarchische Relation
Hallo, hat zufällig jemand ein Beispiel für eine hierarchische Relation aus der Datenbank zur Hand? (Also eine Relation in einer Relation) Am Besten 3+ Ebenen. Die Id würde reichen. Gruß Frederik F. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern im höchsten Zoomlevel bei m Mitbewerber (Was: Google Maps Update?!)
Birgit Nietsch schrieb: > > Was, außer Häusern und Blöcken mit Namen, kann es denn noch geben? > zumindest hier auf dem Land gibt es auch einige Fälle die jeglichem Interpolationsschema widersprechen. Dazu gehören: - sehr unregelmäßige Bebauung - Nummernfolgen wie 7,8,6,9 - generell keine Garantie auf das even/odd Schema Die Variante der Nummern-An-Wegen wäre mir in solchen Fällen viel zu ungenau, abgesehen davon dass ich dann hier am Ende wieder lauter einzelne Segmente statt Wege hätte; vor allem wenn es auch deutlich genauer geht und dass mit - meiner Meinung nach - weniger Aufwand. Bislang bin ich mit dem Karlsruher Schema (wenn auch nicht ganz normgerecht verwendet) sehr gut gefahren. Und die hier erwähnten "not topological" Probleme sind auch unzutreffend, wenn man sauber auf Relations setzt. Gruß Frederik F. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cobra Renderer (war: Osmarender-Der ivat für Windows)
André Reichelt schrieb: > Frederik Fischer schrieb: >> Unter welchen Umständen tritt der Fehler denn auf? (Windows/Mono, >> auch bei geringen Auflösungen des Bildes?) > > Unter Windows XP 32 Bit bei diversen Auflösungen zwischen 2000 und > 6000 Pixeln getestet. > > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de > ich kann das Problem reproduzieren, wenn ich einen ungültigen Pfad für das output-dir angebe. Da fehlt offensichtlich eine entsprechende Validation. (Pfadangabe muss absolut sein und Verzeichnis muss existieren) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] B 1 - Relation laesst sich nicht erweitern
Jonathan Schlüßler schrieb: > Andreas Pothe wrote: > >> Josias schrieb: >> >>> Jonathan Schlüßler schrieb: >>> >>> Mit Potlatch ist es allerdings sehr wohl möglich Relationen anzulegen und zu verwalten. >>> ich weiß nicht, aber bei mir kann ich das seit der umstellung auf >>> deutsch nicht mehr :( >>> >> So sieht es aus. Wobei ich mittlerweile las, dass es nicht funktioniert, >> wenn Potlatch in einem Browser eingesetzt wird, sondern nur bei der >> Verwendung des IE. Und das werde ich mir nicht antun. >> > > Bei mir geht es mit Firefox 3.0.1. > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de funktionieren sollte es eigentlich schon (auch im FF), wirklich brauchbar ist es imho nicht, da die Liste der geladenen Relationen sehr schnell den gesamten verfügbaren Vertikalen Raum einnimmt. Da nicht scrollbar, kann man irgendwann nicht mehr an alle Relationen auswählen. (Zumindest tritt dieses Problem sehr schnell auf, wenn alle Straßen in Straßenrelationen stecken) Im Endeffekt muss ich deswegen immer nach ein paar Aktionen zwangsweise zu JOSM wechseln. Grüße Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Cobra Renderer (war: Osmarender-Der ivat für Windows)
André Reichelt schrieb: > Ah, gibt ja nur Regelfiles für 12 und 17. Sorry. Aber ich habe jetzt > ein anderes Problem. Und zwar zeigt er mit nach dem Rendern der Layer > die Fehlermeldung "ERROR: Allgemeiner Fehler in GDI+". Für die Regelfiles 13-16 war ich zu faul. Kommen noch, wenn ich mir sicher bin, dass das Regelformat so bleibt. Der Fehler muss irgendwo beim Speichern des Bildes auftreten. Bisher hatte ich da nur Probleme, wenn ich eine Auflösung jenseits der 7000x7000 (bzw. selbige Datenmenge) einstelle. Unter welchen Umständen tritt der Fehler denn auf? (Windows/Mono, auch bei geringen Auflösungen des Bildes?) Grüße Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Cobra Renderer (war: Osmarender-Der ivat für Windows)
Hallo, eine kleine Notiz am Rande: Ab sofort ist eine neue (Test-)Version des Renderers unter http://wiki.openstreetmap.org/index.php/User:Ferdi verfügbar. Diesmal nur noch mit GUI und anderen Regelsets. Dafür hoffentlich auch unter Mono lauffähig. viele Grüße Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Breite von Flüssen in Osmarender!
Die Breitenangabe eines Flusses ist ja prinzipiell kein Tipp an den Renderer, sondern ein Datum, dass auch für Routing oder andere Anwendungen interessant sein kann. Nach der gleichen Logik, wäre ja dann die Unterscheidung der highways in primary und secondary auch nur ein Tipp an den Renderer. Grüße Frederik Tobias Wendorff schrieb: > Hallo, > > habe ich auch gerade gedacht ... aber vorhin war noch die Rede davon, > dass wir keine "Tipps" an den Renderer geben sollen. > > Ich bin auch dafür, dem Renderer Beschreibungen zu geben, denn nur > die Dateneingeber wissen, wie die Realität ist. > > Grüße > Tobias > > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Osmarender: highway=gate in falscher Richtung
das liegt daran, dass der Node nicht nur vom Fußweg, sondern auch vom einem leisure=Park Way mitverwendet wird, der parallel zur Straße verläuft. Im vorliegenden Fall wurde das Tor augenscheinlich bezüglich diesen Ways gerendert, was passieren kann, da der Renderer nicht weiß welchen der Ways er als Grundlage für die Ausrichtung verwenden soll. Grüße Frederik Peter Herison schrieb: > Moin moin > > Frage: Warum wird das Tor (Strich zwischen "ß" und "e") quer zu > Füllerstraße gerendert? Eigentlich sollte es, so wie ich es getaggt > habe, den Fußweg in den Park "sperren"... > > http://www.openstreetmap.org/?lat=50.19996&lon=8.57782&zoom=17&layers=0B0FTF > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de > > > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Pfeile in JOSM: Bedeutung?
In den meisten Fällen ist die Richtung des Weges egal. Ausnahmen sind z.B. - Einbahnstraßen ( oneway=yes) : hier orientiert sich die erlaubte Fahrtrichtung an der Richtung des Weges - Küstenlinen ( http://wiki.openstreetmap.org/index.php/Tag:natural%3Dcoastline ) Grüße Frederik Tobias Wendorff schrieb: > Hallo Leute, > > haben die Pfeile bei JOSM eigentlich eine Bedeutung? Ich weiß > immer nicht, wie rum ich einen Weg oder eine Straße einzeichnen > soll. > > Grüße > Tobias > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de > > > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wie Fluss kennzeichnen der im Untergrun d verläuft
Frank Wein schrieb: > Hallo Liste, > wie sollte man am besten einen Fluss kennzeichnen, der im Untergrund, > also durch Bebauung, usw. nicht sichtbar, verläuft? Ich hab mal etwas > mit layer=-1 und tunnel=yes probiert, Osmarenderer scheint das aber noch > nicht umzusetzen. Wie es mit Mapnik aussieht, weiß ich noch nicht. Hat > da jemand eine bessere Alternative parat oder sollte man einfach mal die > Kennzeichnung so lassen wie sie ist und auf eine Änderung des Renderers > warten? > > Gruß > Frank > Mapnik rendert diese Kombination. Meiner Meinung nach ist die Kennzeichnung auch in Ordnung so. Gruß Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Osmarender-Derivat für Windows
Hallo, inzwischen ist eine geringfügig erweiterte Version des Renderers verfügbar. Neu ist eine GUI Version (sehr rudimentär und etwas nervig, weil der Inkscape Pfad (sofern verwendet) bei jedem Start neu eingegeben werden muss). Desweiteren kaum Statusmeldungen, da die noch alle über Console gehen. Ebenfalls neu im Paket, ist der Agg-Modus, der ein wesentlich schnelleres (uns Speicherfreundlicheres) Rendern erlaubt. Da bislang nur eine Testimplementierung, muss noch auf Text, Symbole, Marker, spezielle Styles und Smart-Linecaps verzichtet werden. Download, Hilfe und Beispiele finden sich weiterhin auf http://wiki.openstreetmap.org/index.php/User:Ferdi viele Grüße Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Osmarender-Derivat für Windows
Frederik Fischer <[EMAIL PROTECTED]> wrote: > >> Dafür ist es aber (ab hier nicht überprüfte Provokation) einfacher zum >> laufen zu bekommen, schneller und bietet mehr Raum für komplexere Logik. >> > > Die selben Gründe weshalb Fred orp gemacht hat. > > Sven > ganz genau... nur kann ich Perl absolut nicht ausstehen. Aber wie schon gesagt. Ich will damit nicht osma/orp ersetzen, sondern ein Nebenprodukt zur freien Verwendung stellen, damit es nicht ganz nutzlos vor sich hingammelt. Primär ist das Programm eigentlich als (regelbasiertes) Rendering-Framework, mit dem Ziel sowohl Regelwerk als auch den eigentlichen Renderer modular austauschen zu können, entwickelt worden. Die Referenzimplementierung Osma-Regeln/"Svg-Renderer" ist dabei nur eine mögliche Kombination. Eine weitere wäre zB. Mapnik-Regeln über OpenGL. (auch hierfür habe ich eine (weniger weit fortgeschrittene) Implementierung) Gruß Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Osmarender-Derivat für Windows
Sven Geggus schrieb: > Frederik Fischer <[EMAIL PROTECTED]> wrote: > > >> da ich in letzter Zeit ein wenig mit dem Rendering von osm-Daten >> herumgespielt habe, habe ich hier quasi als Nebenprodukt einen (ca. 90% >> osmarender-kompatiblen, Windows-basierten) Renderer rumliegen. >> > Das irritiert mich jetzt grade ein wenig. Osmarender ist xslt und xslt ist > plattformunabhängig. > > Sven > In der Tat. Meine implementierung des Renderers ist allerdings nicht xslt, und somit nicht zwingend plattformunabhängig. Dafür ist es aber (ab hier nicht überprüfte Provokation) einfacher zum laufen zu bekommen, schneller und bietet mehr Raum für komplexere Logik. Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Osmarender-Derivat für Windows
Hallo, da ich in letzter Zeit ein wenig mit dem Rendering von osm-Daten herumgespielt habe, habe ich hier quasi als Nebenprodukt einen (ca. 90% osmarender-kompatiblen, Windows-basierten) Renderer rumliegen. In der Hoffnung, dass er evtl. für den einen oder anderen brauchbar erscheint, kann man das Teil ab sofort unter http://wiki.openstreetmap.org/index.php/User:Ferdi runterladen und testen. Abgesehen von den auf der Seite erwähnten Schwachstellen, würde ich mich über Feedback (Fehler, falsche Ergebnisse etc.) freuen. viele Grüße Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Tilerequest
Hallo, wäre es möglich, dass mir jemand das Tile x: 17429 y: 11375 z: 15 (ohne subtiles) mit dem osmarender (vorzugsweise or/p) rendern und anschließend das svg file zukommen lassen könnte? Wäre demjenigen sehr verbunden. viele Grüße Frederik F. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zeitdauer vom Hochladen der Daten bis zur Darstellung
Henry Every schrieb: > (...) > Hi, > wenn es gibt wobei man dich unterstützen kann, dann lasse es mich wissen. > mir wäre im Moment sehr viel geholfen, wenn mir jemand mit OpenGL Erfahrung einen Tipp geben könnte wie man am einfachsten eine Textur offscreen rendert und dann in ein Bitmap schreibt ohne ein Fenster erstellen zu müssen. Ist dies überhaupt möglich? Gruß Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zeitdauer vom Hochladen der Daten bis zur Darstellung
André Reichelt schrieb: > Frederik Fischer schrieb: > >> Könnte ja sein dass sich jemand genauer mit dem Tool auseinandergesetzt hat >> (sei es zu Entwicklungs- oder Testzwecken) und deshalb ungefähr weiß in >> welcher Region sich das Verhältnis befindet. >> > Dem Kerl wäre ih sehr verbunden, denn das Ding ist aktuell nicht mehr > wie eine Ressurcenschläuder. Könnte ich programmieren, würde ich mich > direkt nach dem Bugtracker darum kümmern und was gescheites, > hardgecodedes machen, dass ggf. die Grafikkarte zum rendern nutzt und > ohne Inkscape arbeitet, dass teilweise über 12 GB RAM belegt, die dann > virtuell ausgelagert werden müssen. > ich bin im Moment daran aus Spass an der Freude einen möglichst ressourcenschonenden osma-kompatiblen Renderer/[EMAIL PROTECTED] für windows zu schreiben, da meine alte Krücke (athlon 2100+, 512mb ram) laut [EMAIL PROTECTED] nicht gerade als Client-Rechner taugt. Leider hänge ich im Moment an der Inkscape Brücke. Die svg files sind recht flott erstellt, aber das Rasterisieren mittel Inkscape dauert. (svg erstellen: ca. 1s, in png umwandeln: ca. 7-15s) Aus diesem Grund bin bzw. war ich interessiert, ob inkscape generell etwas verzögert und wie die anderen möglichkeiten (rsvg,...) in dieser Hinsicht abschneiden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zeitdauer vom Hochladen der Daten bis zur Darstellung
André Reichelt schrieb: > Frederik Fischer schrieb: > >> hat zufällig jemand etwas genauere Angaben zur Hand. Mich würde konkret >> interessieren, wie lange es in etwa dauert, ein Tile mit orp in einer >> Zoomstufe zu rendern (...) >> > Da wirst Du keine genauere Antwort bekommen können. Erstmal ist es eh > egal, wie lange nur ein einzelnes Tile gerendert wird, da grunssätzlich > IMMER der ganze Satz gerendert wird. Zweitens kommt es ganz auf die > Komplexität des Ganzen an. Außerdem liegen die Tiles nach dem Rendern > noch auf dem Server rum, der die entpacken muss und auch dabei können > mehrere Stunden vergehen. (...) das ist mir schon klar. Mir geht es eher um die Verteilung der Rechenzeit zwischen Rendern und Rasterisierten. Könnte ja sein dass sich jemand genauer mit dem Tool auseinandergesetzt hat (sei es zu Entwicklungs- oder Testzwecken) und deshalb ungefähr weiß in welcher Region sich das Verhältnis befindet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zeitdauer vom Hochladen der Daten bis zur Darstellung
Bernd Wurst schrieb: > Osmarender ist (richtig übel) langsam. Für ein Tileset (ein Bildchen bei Zoom > 12 und alle Bilder der höheren Zoomstufen des selben Bereichs) braucht das > abhängig von der Zahl der Elemente zwischen mehreren Minuten und über einer > Stunde. Aufgaben für [EMAIL PROTECTED] werden von Benutzern manuell, von > Admins per > Script und per Überwachung der Änderungen am Datenbestand erstellt. > [EMAIL PROTECTED] ist chronisch überlastet. hat zufällig jemand etwas genauere Angaben zur Hand. Mich würde konkret interessieren, wie lange es in etwa dauert, ein Tile mit orp in einer Zoomstufe zu rendern (also ohne Subtiles höheren Zooms; mittlere Komplexität angenommen) und vor allem: wieviel der Zeit für die Rasterisierung des svg-files draufgeht. Gruß Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potalch 0.9a Tastaturprobleme?
PHerison schrieb: > Hat noch jemand Probleme mit Tastenkuerzeln unter Potlach? Ab und an > passiert es hier, dass Tastatureingaben nicht mehr angenommen werden. > Das ist insbesondere aergerlich bei und . > An wen wendet man sich bei sowas? > selbiges passiert bei mir immer wenn ich einen Tabwechsel mache. Interessanterweise funktioniert es wieder, wenn ich, bevor ich in den Potlach-Tab wechsle, erst in einen Tab mit openstreetmap.org aktiviere. Gruß Frederik (F.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
