Ich hab sie bis jetzt nur in den
properties verwendet (geht aber glaub ich auch in den target’s) und da sehen die so aus:
map.rendering.lflp.min-buffer-space : 5
map.rendering.lflp.max-allowed-corner-angle : 50
map.rendering.lflp.max-compression : 0.9
Im Rules-Ordner in der Hilfe.txt sind noch andere aufgeführt
z.B. map.rendering.topmost-layer um Linien oder Flächen ganz oben zu positionieren auch wenn sie Layer=-4 oder in der hirachie weiter unten stehen würden da kann man dann gezielt Radwege über alle anderen Linien legen usw.
Hi,
um das ganze mal zusammenzufassen:
In Maperitive hast du mit relation[network=lwn] Zugriff auf alle Wege, die in lwn-relationen stecken. Nicht aber auf die tags der Relationen.
Deshalb kannst du bunte Linien für Wanderrouten zeichnen, wie Igor es in seiner hiking.mrules vormacht. Mehr konnte Kosmos auch nicht. Im name-tag steckt nämlich weiterhin nur der Name des Weges, ebenso bei ref.
Mkgmap löst das Problem, indem die Relationstags als route_name und route_ref an alle Mitglieder der Relation gehangen wird. Das wird aber dann problematisch, wenn mehrere Routen den gleichen Weg benutzen.
Das py-Script oben hängt die refs dann wohl irgendwie hintereinander.
Osm2pgsql löst das Problem für Mapnik, indem zusätzliche Wege erzeugt weren, die nur die Tags der jeweiligen Relation haben. Für Routingzwecke ist der Ansatz natürlich nicht zu gebrauchen, aber die Collision detection für Schildchen und Beschriftung sieht ganz ordentlich aus.
Und dann wäre da noch der Map Composer. Nop hatte natürlich anfangs die gleichen Probleme wie du. Er legt einfach zusätzliche Knoten in den lokalen osm-Datensatz, die er für die Platzierung der Icons entlang der Routengraphen ausgesucht hat. Hier wird die collison detection also vom Renderer in den Composer verlagert. Die Icons legt der Map Composer auch gleich in ein eigenes Verzeichnis.
Du kannst jetzt natürlich dein Extrakt durch den Map Composer schicken, und den so erzeugten Kosmos-Datensatz probehalber mal Maperitive vorsetzten. Du musst dann nur in den osmc-rules für Kosmos schauen, welche tags er für die icons vergeben hat, und entsprechende Regeln für Maperitive erstellen. Die Routenbeschriftung in Maperitive schaltest du dann am besten ganz ab.
Im Prinzip könntest du mit den Autobahnicons genauso verfahren, da es ja für jede Autobahn Relationen gibt.
Gruß,
ajoessen
Vielen Dank!
… wenn man den Wald vor lauter Bäumen nicht mehr sieht … lach … dann merkt man gar nicht, daß der Befehl in den eigenen properties bereits korrekt eingebaut ist. kopfklatsch
Mein Befehlaufruf war falsch.
In der Anleitung steht (bislang) auf genannter Seite kein Beispiel für die Syntax. So hatte ich (falsch!) nur “lflp.min-buffer-space : xx” eingebaut.
Das konnte ja nichts werden.
Mit der korrekten Syntax wird der Befehl auch in den rules akzeptiert und ermöglicht so, den Wert für ein einzelnes Target einzustellen.
Prima 
@ ajoessen
Interessante Gegenüberstellung!
Da es möglicherweise aus dem Heureka-Post #39 nicht ganz klar hervor geht, hier allein die speziellen Möglichkeiten von Maperitive:
Maperitive kennt mindestens zwei (wahrscheinlich sogar drei ?) Möglichkeiten, auf Routen-Relationen zuzugreifen:
-
: relation[TAG=KEY]
-
: osmnetwork[TAG=KEY]
-
irgendwie mit py-script
zu 1:
Ein so definiertes Feature sammelt alle Wege ein, deren übergeordnete Routenrelationen den angegebenen Kriterien entsprechen. Die in den Routenrelationen hinterlegten Tags werden in den RULES jedoch nur teilweise ausgewertet. In der Routenrelation hinterlegte REF und NAME bleiben beispielsweise unberücksichtigt. Dadurch ist es möglich, Wegenetze sichtbar zu machen, und gleichzeitig am einzelnen Weg hängende Informationen abzurufen.
zu 2:
Ein so definiertes Feature sammelt ebenfalls alle Wege ein, deren übergeordnete Routenrelationen den angegebenen Kriterien entsprechen. Jedoch können in diesem Fall auch in der Routenrelation hinterlegte Werte aus REF und NAME in den Rules ausgewertet werden. Dadurch ist es möglich entsprechende Schildchen zu generieren, oder die Routennamen am Weg entlang anzuzeigen. Hierbei kommt es zu Überlagerungen von Straßennamen und aus anderen Routennetzwerken stammenden Schriftzügen. Dieses Problem läßt sich durch text-offset lösen.
Keine Lösung fand ich bislang für das Problem, daß immer nur ein Routenname angezeigt wird, wenn mehrere aus demselben Routennetzwerk stammende Routen einen Weg gemeinsam benutzen. Dafür muß man dann eine *.py einbauen. Nur wie das funktioniert, hab ich noch nicht heraus bekommen.
Eine Beobachtung, die ich noch nicht gut beschreiben kann.
Daher nur eine Anregung zum selber Schauen:
Je nach dem, mit welchem Feature (also entweder auf relation oder auf osmnetwork bezogen) der Weg der Route erstellt wird, verändert sich das Verhalten der Linien irgendwie.
Die Option relation eignet sich meinen Tests zufolge besser zum Anzeigen der linienförmigen, wegbegleitenden Routenmarkierung.
Daher setze ich beide Optionen für die Definition der features ein.
Gruß
tippeltappel
Ja, osmnetwork ist wohl noch ganz neu bei maperitive. So neu, dass es leider noch gar nicht dokumentiert ist 
Natürlich kannst du das osmc:symbol damit dann auch auslesen.
Das py-script hängt alle refs der beteiligten Routen hintereinander. Auch ne Lösung.
Aber ich glaube, die Map-Composer-Kosmos-Alternative erledigt das eleganter.
Meine Behauptung aus Post #2 halte ich aber nach wie vor aufrecht 
Gruß,
ajoessen
Die Geheimnisse der Programmierer entdecken ist doch spannend!
Wenn man in Mapnik ohne Datenbank auskäme, hätte ich das Programm bestimmt schon ausprobiert.
Aber wie man sieht, kommt man mit Maperitive auch schon ganz schön weit. - Ohne Datenbank.
Die Auswertung der osmc:symbole wird eine neue interessante Baustelle.
Wobei mich der Umgang mit *.py-Dateien im Moment mehr interessiert.
Ich würde gerne Scripte ineinander verschachteln. So ähnlich, wie man in Dos z.B. mit call Scripte aufruft.
Viele Grüße
tippeltappel
** … man das Renderergebnis von Maperitive als dynamische Karte “verwahren” kann?" **
Wenn man ein größeres Gebiet mit Maperitive rendert, dauert es einige Zeit, bis das Gebiet angezeigt wird. Ein Umschalten zwischen verschiedenen Kartenstilen ist daher nicht so ohne weiteres möglich, wäre aber ganz reizvoll.
Die bislang entdeckten Export-Funktionen zielen alle darauf ab, das Renderergebnis als Bitmap, *.svg oder Rasterkarten-Tiles zu speichern.
Das ist aber alles nicht das, was ich im Augenblick suche. Schön wäre, wenn das mit einem Script zuletzt erzeugte Renderergebnis aus einem Cache hervorgeholt werden könnte.
Unter “Tools” gibt es den Befehl “Clear Web Map Tile Cache”. Der führt leider in eine ganz andere “Richtung”. Kennt jemand eine verborgene “Schatzkammer” in der das Renderergebnis stecken und abrufbar sein könnte?
Gruß
tippeltappel
womisa
48
Hi
frage doch beim Meister nach ==> http://groups.google.com/group/maperitive
MfG
Achim
Hab’s mal probiert.
Bin aber kein google-gruppen-fan.
Gruß
tt
