Talk:Cobra

was sind die blauen Linien bei Freising? cycleway-lanes? --Cbm 13:14, 26 July 2008 (UTC)

Das ist eine Demo Einstellung in den Regeln um zu zeigen, wie man z.B. cycleway-lanes darstellen könnte. Die Einstellung gilt aber im Moment für alle primary, secondary und tertiary highways ohne Rücksicht auf cycleway-lanes. --Ferdi 13:25, 26 July 2008 (UTC)

könnte man auch neben dem cycleway= noch das footway= (z.B. für Bürgersteige zu mappen siehe Proposed_features/Footway) berücksichtigen? Quasi noch eine Linie neben den cycleway ggf. auf beiden Seites des Ways... wäre sehr cool :) --Cbm 19:04, 26 July 2008 (UTC)

Kommandozeilenversion

31.07.2008 - Hallo Ferdi, ich (Friedel) benutze noch die Kommadozeilenversion osm.rendering.democlient.console.0.2.1.rar. Ich rufe sie von einem Perl-Skript aus auf und rendere mir so mit modifizierten Regeln eigene Karten für Glopus.

Ich will das auch gelegentlich dokumentieren. Kannst du die Kommandozeilenversion parallel weiter pflegen oder alternativ wenigstens die letzte (so schlecht ist die 0.2.1 doch gar nicht ;-) ) weiter zum Download für Interessierte bereit halten?

Welchen Modus verwendest du beim democlient? Wenn du denn AGG Modus verwendest, kann ich dir anbieten eine Kommandozeilenversion des Cobra Renderers zu erstellen. Wenn Svg (was ich vermute), dann ist das etwas schwieriger. Aber ich denke ich könnte in einer der nächsten Cobra Versionen den "alten" SVG Renderer integrieren (+ Kommandozeile), das wäre dann einfacher als zwei Programme parallel zu pflegen.

Richtig - ich verwende noch den SVN-Modus. AGG-Modus müsste ich mal probieren. Ich meine, ich kann eigentlich mit der 0.2.1 gut leben, nur wäre ich dann von deinen Verbesserungen abgekoppelt.

Feature Requests

footway=* nur einseitig gerendert

in deinem Demo-Screenshot hast du die Wege auch (nur einseitig) geschafft. wie geht das? bei mir mal er sie momentan auch bei left/right immer auf beide Seiten. --Cbm 13:11, 7 August 2008 (UTC)

ich habe die Regeln zur aktuellen Version etwas überarbeitet Die Überarbeitung betraf auch die fuß/radweg-lanes. Das ganze ist aber nur rudimentär und quasi ungetestet eingebunden, da ich bislang keinen brauchbaren Datensatz gefunden habe, an dem ich das Ergebnis überprüfen könnte. (falls du da einen Bereich weißt in dem entsprechende Tags vorkommen: immer her damit, dann kann ich es evtl. in die nächste Version noch integrieren). --Ferdi 13:25, 7 August 2008 (UTC)

habe mich hier mal was "ausgetobt" ;) http://www.informationfreeway.org/?lat=50.768718125391295&lon=6.10930617282839&zoom=16&layers=B000F000F --Cbm 13:26, 7 August 2008 (UTC)

wusste gar nicht, dass osma und mapnik die footway(left|right|both) schon rendern...

tun sie nicht.. ich habe bis gestern noch einzelne footways eingezeichnet, die ich aber zum testen deines Renderers wieder gelöscht habe (schließlich siehts wenn dein Renderer das auch richtig kann sogar besser aus und ist einfacher zu erfassen ;) ) --Cbm 17:17, 7 August 2008 (UTC)

hab mich schon gewundert das weder in regeln noch in Code was zu finden war. Abgesehen davon, dass es bei beiden gleich positioniert war, und eher danach aussah als hätte ein Preprozessor die Wege dort reingerechnet. :)

aber so in der Art darfs gerne aussehen mit Cobra ;) --Cbm 17:35, 7 August 2008 (UTC)

cycleway=*

wäre es auch möglich, die cycleways 'in' die Straße zu zeichnen? Die footways werden ja 'auaßerhalb' gezeichnet. bei cycleway macht das aber nur wirklich bei cycleway=track (cycleway=opposite_track) sind cycleway=lane (cycleway=opposite_lane würde eher innerhalb Sinn machen ( cycleway=opposite mit einer Spur einzeichnen ist auch fragwürdig, weil es schnell missverstanden wird, als weg, der nciht da wäre). ich hoffe du findest diesen Wuunsch für sinnvoll (und er lässt sich realisieren ;) ). Besonders wenns später mal noch größere Zoomstufen als z=17 gibt könnte dieses Feature sehr interessant werden, denke ich :) --Cbm 23:10, 9 August 2008 (UTC)

prinzipiell eigentlich kein Problem. Aber in der momentanen Größe würde recht wenig von der Straße übrig bleiben. Aber man ist ja frei ein Regelset für detailliertere Darstellungen zu erstellen. (Wobei ich befürchte, dass ab einer gewissen "Nähe" die üblichen Zeichenartifakte, die man bislang nur bei genauerem Betrachten sieht, zu offensichtlich und unschön werden.) --Ferdi 11:39, 10 August 2008 (UTC)

crossing=*

vielleicht in rot, damit der mögliche Gefahrenbereich signalisiert wir? oder vielleicht einfach nur die gestrichelte aussenlinie eines footways? :) --Cbm 15:52, 8 August 2008 (UTC)

Lane-Relations auslesen und nutzen

Damit man in Hohen Zoomstufen bessere Renderergebnisse bekommt, könnten Lanerelations die Lösung sein. Denn man bräuchte Radwege nicht mher über irgendwelche pseudo-Abstände von der Mitte des Weges zu definieren, denn der Bezug der einzelnen Spuren zueinander definiert sich durch die Relations. Mehr Info unter: Proposed_features/lane_and_lane_group --Cbm 08:54, 15 January 2009 (UTC)

Danke für die Info. Ich lese selbst ab und zu in der Diskussion mit, war aber der Meinung, dass man sich bislang noch nicht auf eine entgültige Lösung einigen konnte.

Im Moment versuche ich den letzten Schritt der Umstrukturierung des Programms fertig zu stellen. Danach sollte es auch wesentlich einfacher sein etwas komplexere Regeln wie die lane groups besser umzusetzen. Ebenfalls angedacht ist eine Umsetzung der Layer-Relationen. (Sofern es da mal ein Proposal geben sollte.) --Ferdi 10:10, 15 January 2009 (UTC)

was ist eine Layer-Relation? --Cbm 16:44, 15 January 2009 (UTC)

Eine Relation als Alternative zu den layer-Tags. (Alle Ways/Nodes die sich kreuzen/übereinander liegen kommen in eine geordnete Relation (bzw ungeordnet mit layer-Angaben)) Bislang gibt es meines Wissens außer rein theoretischen Überlegungen weder ein konkretes Proposal noch die Absicht ein solches in nächster Zukunft zu erstellen. Eine solche Relation könnte das Rendern nicht unwesentlich beschleunigen, und würde die implizite 11-Layer Einschränkung unnötig machen. Nachteilig ist, dass die korrekte Interpretation einer solchen Relation im Gegensatz zu der layer-Tag-Variante nicht unbedingt trivial zu implementieren ist. Inwieweit die Vorteile die Nachteile aufwiegen ist Ansichtssache. --Ferdi 20:04, 16 January 2009 (UTC)

Specification_of_Cobra_Rules_v1.pdf

Der Link dorthin im Artikel geht nicht mehr --Mueck 19:47, 24 January 2009 (UTC)

Oh, danke. Die wurde wohl beim Serverumzug vergessen. Macht aber nichts, da schon ein wenig veraltet. Bald gibt's Ersatz dafür.

schön :-) --Mueck 00:00, 26 January 2009 (UTC)

Osmarender Änderungen

Hab's nun erfolgreich installiert und war gleich mit Original Osmarender Styles gescheitert, während etwas ältere gingen. Es scheint daran zu liegen, dass da gerade frisch was von Text auf pathText und areaText umgestellt wurde oder so? Bitte mal die Kompatibilität prüfen und ggfs. nachführen ;-) --Mueck 00:00, 26 January 2009 (UTC)

das kann gut sein. Meine Osmarender Test Styles din schon etwas älter. Ich werde mir das mal anchauen. --Ferdi 09:39, 26 January 2009 (UTC)

"amtliche" Zoomstufen und bbox

Mal angenommen, ich lade ein Kartenschnippsel via API und scheuche das durch Cobra... Wie kriege ich ein PNG, dass dieselbe Auflösung wie sie zu der per style gewählten Zoomstufe passend auch in der slippy map verwendet wird? Man kann zwar die Bildbreite vorgeben, aber dazu müsste man wissen

• von wo bis wo Cobra rendert, denn im Schnippsel sind ja auch die Teile drin, die außerhalb des beim API-Aufruf gewählten Ausschnitts liegen, weil sie in den Ausschnitt reinreichen, ist also nicht so ganz trivial rauszukriegen...
• wie man daraus dann die Bildbreite rechnet und wo man überhaupt die Meter pro Pixel oder so findet...

Nett wäre statt einer Bildbreitenangabe eine Möglichkeit für "ich hätte gerne dieselben Meter pro Pixel wie bei der slippy map für Zoomstufe 17 gewählt", evtl. sogar als Default, wenn 0 nicht geändert wird. Dann könnte man Cobra als eine Testumgebung für Osmarender-styles nehmen. Irgendwie habe ich noch kein anderen SVG-->PNG zum laufen gekriegt... Nett wäre auch ein Button "berücksichtige die bbox im .osm, schmeiß den Rest weg" ;-) --Mueck 00:00, 26 January 2009 (UTC)

Bislang ist das ganze so konstruiert, dass praktisch Zoomunabhängig gerendert wird. Ich denke ich werde das für die nächste Version wieder ändern, und eine solche "Auto-Width" Funktion einbauen. Ansonsten lässt sich das natürlich auch manuell berechnen. (es wird die in der OSM Datei gegebene Boundingbox gerendert. Alles darüberherausragende wird abgeschnitten. Benutzerfreundlich ist das natürlich eher weniger.) --Ferdi 09:49, 26 January 2009 (UTC)

Bei mir schneidet der irgendwie nix anhand der bbox ab... --Mueck 23:34, 26 January 2009 (UTC)

Die Daten an sich werden in der Tat nicht Abgeschnitten. Dies hat aber nur für die SVG Ausgabe Auswirkungen, da dort Daten aus der viewbox gerausragen. Die viewbox (also das was auch beim anschließenden rasterisieren sichtbar wäre) ist auf die bbox begrenzt. Einzige Ausnahme: wenn keine bbox im osm file definiert ist, wird sie nachträglich aus den Extremwerten berechnet. --Ferdi 09:48, 27 January 2009 (UTC)

Nehme alles zurück und behaupte nun spontan das Gegenteil. Nach Putzen der Brille entpuppte sich die gueltige bbox als Kommentar der API <osm ... osmxapi:uri='/api/0.5/*[bbox=8.36,49.019,8.373,49.024]' ... /> Wenn ich das in eine richtige box umfriemel, klappt das Wegschnibbeln... ;-) Jetzt bliebe nur noch die Frage, wo ich finde, wie ich die breite ausrechne, sprich: welcher "Maßstab" welcher Zoomstufe entspricht. ist mir glaub noch nicht über den Weg gelaufen... --Mueck 11:04, 27 January 2009 (UTC)

im zweifel noch 1-3 Tage warten, dann wird die 0.3.9er Version hoffentlich fertig sein. (Einziger offener Punkt ist noch das Prüfen und ggfls Aktualisieren der Osmarenderregeln) Im Moment würde ich sowieso empfehlen nicht zu viel Arbeit in die aktuelle Version zu investieren, da das Projekt-Format einer grundlegenden Revision unterzogen wurde und es aufgrund der teilweise massiven Änderungen keinen Kompatibilitätsmodus geben wird. --Ferdi 12:40, 27 January 2009 (UTC)

Ok, dann warte ich noch 3-9 Tage frei nach Murphy ;-) Ob die Version dann womöglich auch solche "falschen" bboxen nimmt? ;-) --Mueck 14:11, 27 January 2009 (UTC)

Mapnik Rule interpreter

Ist auch sowas neben dem Osmarender rule interpreter geplant? Auch als Testumfeld für style-Änderungen, weil die Mapnik-eigene Umgebung scheint etwas komplexer zu sein... --Mueck 00:00, 26 January 2009 (UTC)

angedacht sind sowohl ein Mapnik Plugin wie auch eines für Kosmos Regeln. Allerdings ist auch meine Zeit endlich, weshalb ich im Moment keine festen Zusagen diesbezüglich machen kann. Ein Schritt in diese Richtung wäre schonmal die Unterstützung für Raster-Icons, die wohl ziemlich sicher irgendwann kommen wird. --Ferdi 09:27, 26 January 2009 (UTC)

einseitiges

Wie man einseitiges, z.B. Radwege, gerendert kriegt, habe ich auf diesen Seiten noch nicht wirklich verstanden, bitte um kurze Nachschulung :-) --Mueck 00:03, 26 January 2009 (UTC)

Einseitige Pfade werden über ein offset casing "gefaked". Dies geht aber nur in den Cobra-Regeln mittels dem offset Attribut für die line Visualisierung. Da Osmarender im Grunde nur die SVG Attribute unterstützt und ich nicht irgendwelche eigenen Regelerweiterungen vornehmen wollte, ist das Osmarender Plugin entsprechend beschränkt. --Ferdi 09:37, 26 January 2009 (UTC)

Cobra#Images shows 404. --Kolen 12:45, 5 February 2010 (UTC)