Maperitive - Wer weiß, wie ...

ajoessen · 2011-11-24T13:11:04.000Z

tippeltappel:

Und ich dachte, das reicht.
Funzt aber irgendwie nicht.

Wo kann es noch hängen?

Nur geraten: da muß bei allen Relationen ein relation [ ] drumherum?

Gruß,
ajoessen

tippeltappel · 2011-11-24T13:24:40.000Z

Verstehe jetzt nicht, wie Du das meinst.

ajoessen · 2011-11-24T13:42:38.000Z

Probier mal

relation[route=horse]

statt

route=horse

Denn die route=* hängen doch nicht an den Wegen, sondern an Relationen, oder nicht?

Leerzeichen zwischen relation und [ könnte auch stören.

In den hiking.mrules stecken auch noch ein paar Relationen drin:


    lines
        aerialway : aerialway
        contour major : contour[@isMulti(elevation, 50)]
        contour minor : contour[@isMulti(elevation, 10) and not @isMulti(elevation, 50)]
        hiking route : relation[type=route route=foot] way[trailblazed=yes]
//        hiking route major : relation[type=route route=foot @isOneOf(network, iwn, nwn)]
//        hiking route minor : relation[type=route route=foot @isOneOf(network, rwn, lwn)]
//        hiking route other : trailblazed=yes

Gerade noch gefunden:

How do I define a relation rule?

By defining a feature which targets relations, for example:

features
lines
cycling route : relation[type=route AND route=bicycle]
…
rules
target : cycling route
…

This example is for stuff you want to draw as lines. If you have a relation which is used for areas (I cannot remember any example of this), you would define the feature under the “areas” subsection.

Die Relationen müssen also unter lines stehen.

gruß,
ajoessen

quasilotte · 2011-11-24T13:51:36.000Z

Relationen direkt Auswerten geht mit Maperitive (noch) nicht!

Es wird zwar auf die Daten der Relation zugegriffen ausgewertet werden aber die WAYS [draw : line ]

Es fehlt noch die Möglichkeit auch Relationen als Objekt auswerten zu können nicht nur als Kriterium zu nutzen!

Gibt eigentlich mommentan nur 3 Objekte Nodes Ways und Ways die eine Area bilden (Was dann indirekt auch für nee Relation gilt).

Denn GPX kram aussenvor gelassen!

PS: Was gehen könnte währe über python
Siehe Hier ist ein Beispiel für CycleLabel

http://braincrunch.tumblr.com/post/4286086882/maperitive-python-scripting-introduction

tippeltappel · 2011-11-24T14:07:54.000Z

ajoessen:

Probier mal

relation[route=horse]

statt

route=horse

Denn die route=* hängen doch nicht an den Wegen, sondern an Relationen, oder nicht?

Leerzeichen zwischen relation und [ könnte auch stören.

In den hiking.mrules stecken auch noch ein paar Relationen drin:
    lines
        aerialway : aerialway
        contour major : contour[@isMulti(elevation, 50)]
        contour minor : contour[@isMulti(elevation, 10) and not @isMulti(elevation, 50)]
        hiking route : relation[type=route route=foot] way[trailblazed=yes]
//        hiking route major : relation[type=route route=foot @isOneOf(network, iwn, nwn)]
//        hiking route minor : relation[type=route route=foot @isOneOf(network, rwn, lwn)]
//        hiking route other : trailblazed=yes
Gerade noch gefunden:

How do I define a relation rule?

By defining a feature which targets relations, for example:

features
lines
cycling route : relation[type=route AND route=bicycle]
…
rules
target : cycling route
…

This example is for stuff you want to draw as lines. If you have a relation which is used for areas (I cannot remember any example of this), you would define the feature under the “areas” subsection.

Die Relationen müssen also unter lines stehen.

gruß,
ajoessen

Vielen Dank für die “Spielideen”
Die Syntax stimmt aber wohl grundsätzlich. Denn Maperitive meckert sofort, wenn irgendwo eine Winzigkeit (z.B. eine Leerstelle) falsch gesetzt ist.

Und ja, diese Definitionen habe ich unter lines stehen.

tippeltappel · 2011-11-24T14:17:39.000Z

quasilotte:

Relationen direkt Auswerten geht mit Maperitive (noch) nicht!

Es wird zwar auf die Daten der Relation zugegriffen ausgewertet werden aber die WAYS [draw : line ]

Es fehlt noch die Möglichkeit auch Relationen als Objekt auswerten zu können nicht nur als Kriterium zu nutzen!

So was habe ich befürchtet. Denn die beobachteten Render-Ergebnisse sind da recht eindeutig.

quasilotte:

Gibt eigentlich mommentan nur 3 Objekte Nodes Ways und Ways die eine Area bilden (Was dann indirekt auch für nee Relation gilt).

Denn GPX kram aussenvor gelassen!

Was dann in der Sektion features zu entsprechend gegliederten Aufrufen führt.
Da fehlt also sozusagen die Abteilung “Relation”.

Schade. Deshalb konnte ich auch noch keine Möglichkeit finden, das osmc:symbol-TAG auszuwerden.

quasilotte:

PS: Was gehen könnte währe über python
Siehe Hier ist ein Beispiel für CycleLabel

http://braincrunch.tumblr.com/post/4286086882/maperitive-python-scripting-introduction

Mit Python kenne ich mich nicht aus und hab leider gerade auch keine Zeit, mich da reinzuknien.

@ beide
Nop rendert seine online-Karte wohl mit Kosmos. Die enthält die “Schildchen”. Hat Kosmos da andere Funktionen als Maperitive?
Maperitive ist doch der Nachfolger von Kosmos. … - ? -

Viele Grüße
tippeltappel

womisa · 2011-11-24T14:27:04.000Z

quasilotte:

Ja mit 32 Bit Systemen ist es eigentlich nicht mehr sinnvoll möglich ansehnliche Bereiche zu Rendern.

Ich selbst hab win7 64 Bit mit 16GB.

Für mich hat sich es gezeigt das so Gebiete um die Zoom 8 + Rand das beste Verhältniss ist zwischen Größe und Rendergeschwindigkeit!

…das verstehe ich wirklich nicht! Dem Ruf nach einem 32 Bit System folgt dann der Ruf nach einem 128 Bit System… Ok, Der Bus ist 64 Bit und dass mehr Speicher atwas für die Geschwindigkeit bringt ist schon klar. Ich kenne aber performante Datenbanken mit mehreren Gigabyte an Daten. Das Rendern auf einem 32 Bit System mit Maperitive darf doch keine Beschränkung für das Rendern großer Gebiete sein. Es ist auch klar, dass wenn man ALLES ins Memory holt schnell die Grenzen erreicht sind. Aber man hat ja noch eine Platte zum auslagern… Es ist vollkommen klar, dass das auf die Geschwindigkeit geht…

Ich bin da aber voller Hoffnung, da Maperitive wohl zukünftig für solche Zwecke eine SQLite_Datenbank einsetzen will.

Also am 32 Bit System liegt das sicherlich nicht, sondern an der Art der Implementierung.

Ps.: Stichwort bei der XML-Verarbeitung XmlDocument vs. SAX Parser…

ajoessen · 2011-11-24T14:27:57.000Z

tippeltappel:

@ beide
Nop rendert seine online-Karte wohl mit Kosmos. Die enthält die “Schildchen”. Hat Kosmos da andere Funktionen als Maperitive?
Maperitive ist doch der Nachfolger von Kosmos. … - ? -

Viele Grüße
tippeltappel

Ja, mit Kosmos habe ich auch mal angefangen:
http://wiki.openstreetmap.org/wiki/User:Ajoessen/Kosmos

Nop wird aber wohl für seinen Server auf Mapnik setzen. Die Kosmos-Anbindung ist eher für Kleinanwender wie du und ich gedacht.

BTW setzt nop die Schildchen semi-manuell als Punkte an die Linien.

Gruß,
ajoessen

tippeltappel · 2011-11-24T14:39:59.000Z

@ quasilotte
Hab mal eben schnell das Beispiel ausprobiert.
Ergebnis:


> run-script "C:\OSM-Karten-erstellen\Maperitive\meineScripts\farbigeHintergrundkarte_WanderroutenHintergrund_Reitrouten_Eifel.mscript"
   > clear-map
   > use-ruleset location=meineRules\farbigeHintergrundkarte_Musterflächen_WanderroutenHintergrund_Reiter.txt as-alias=farbigeHintergrundkarteWanderroutenReitrouten
      Rendering rules could not be parsed:
      ERROR: import-script does not support nested statements (line=139, col=2)
   SCRIPT FAILED
   Script execution error (line 2): Rendering rules could not be parsed

Ideen?

Später mehr.

Gruß
tippeltappel

tippeltappel · 2011-11-24T17:18:14.000Z

** Gefunden ! **

Und es gibt sie doch, die Routenauswertung!

Zunächst hatte ich versucht, den Code von BrainCrunch mitsamt *.py-Datei in mein Skript zu integrieren.
Daraufhin ergab sich der gepostete Fehler.

Die Datei mit dem übernommenen Code nannte ich cyclelabel.py


def cycleLabel(e):
    str_list = []
    for set in e.tagSets:
        if set.hasTag('ref'):
            str_list.append(set['ref'])

    str_list.sort()
    return '+'.join(str_list)

Gemäß Vorlage baute ich in meinem Script einen Aufruf dieser Datei ein. Dabei fiel mir auf, daß die Definition des Routen-Features nicht mit dem Wort “relation” sondern mit dem Wort “osmnetwork” erfolgte. Also änderte ich das Script entsprechend:



features

//******************************************************************************

    areas
//---------------
...

//******************************************************************************

// Python Code importieren

import-script:cyclelabel.py


//******************************************************************************
    lines
//---------------
//Routen
    // Fahrradrouten
        route Fahrrad : osmnetwork [type=route AND route=bicycle]

...

//******************************************************************************
properties
//******************************************************************************
...

//******************************************************************************
rules
//******************************************************************************
...

//******************************************************************************
// 19.02 Markierung Fahrradrouten
//---------------------------------------------------------------------------
// route Fahrrad : osmnetwork [type=route AND route=bicycle]

    target : route Fahrrad
        define
            min-zoom : 11
            line-color : white
            line-width : 5
            line-style : solid
            line-opacity : 0.01

            min-zoom : 11
            border-color : blue
            border-style : solid
            border-width : 5
            border-opacity : 1

        for : tunnel=yes
            define
                border-style : dot
        draw : line

        define
                 text-func : cycleLabel(e)
        draw : text

Dieser Code provozierte die zuletzt gepostete Fehlermeldung.

Da ich nicht dahinter kam, welche Verschachtelung gemeint ist, die das Import-Script nicht unterstützt, deaktivierte ich alle Befehlszeilen, die mit dem Aufruf der *.py zu tun haben.

Kaum war die Änderung gespeichert, startete Maperitive die Aktualisierung. Die dauerte länger, als gewohnt. Grund: alle Relationen wurden nun durchforstet und die darin enthaltenen ref auf die Wege geschrieben.

Nachdem ich den Aufruf der Wanderrouten-Relationen ebenfalls geändert hatte, tauchten deren Namen nicht nur am Weg, sondern auch auf den Schildchen auf, die sich nun ganz anders auf dem Weg verteilten.

Da ich sowohl Wanderrouten als auch Fahrradrouten aufrufe, ist das optische Ergebnis sehr chaotisch. Da muß ich noch “schrauben”, damit unleserliche Überschneidungen verschwinden. Aber jetzt sind die Routen-Bezeichnungen wenigstens schon mal da!

Viele Grüße
tippeltappel

*EDIT - Tippfehler im Code korrigiert

tippeltappel · 2011-11-25T00:31:11.000Z

** … die Beschriftung kurzer Straßenabschnitte unterbunden wird? **

Auf dieser Handbuchseite wird ein sehr praktisches Feature beschrieben:
http://maperitive.net/docs/manual/Label_Placement.html

Durch Setzen eines Buffer-Wertes kann man - wenn ich die Anleitung richtig verstehe - die Anzeige von Straßennamen auf kurzen Fragmenten unterdrücken.
Nur leider meckert Maperitive, der Befehl sei unbekannt.

Weiß jemand eine Lösung?

Gruß
tippeltappel

quasilotte · 2011-11-25T06:01:46.000Z

tippeltappel:

** … die Beschriftung kurzer Straßenabschnitte unterbunden wird? **

Auf dieser Handbuchseite wird ein sehr praktisches Feature beschrieben:
http://maperitive.net/docs/manual/Label_Placement.html

Durch Setzen eines Buffer-Wertes kann man - wenn ich die Anleitung richtig verstehe - die Anzeige von Straßennamen auf kurzen Fragmenten unterdrücken.
Nur leider meckert Maperitive, der Befehl sei unbekannt.

Weiß jemand eine Lösung?

Gruß
tippeltappel

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.

ajoessen · 2011-11-25T06:17:04.000Z

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

tippeltappel · 2011-11-25T10:21:23.000Z

quasilotte:

tippeltappel:

** … die Beschriftung kurzer Straßenabschnitte unterbunden wird? **

Auf dieser Handbuchseite wird ein sehr praktisches Feature beschrieben:
http://maperitive.net/docs/manual/Label_Placement.html

Durch Setzen eines Buffer-Wertes kann man - wenn ich die Anleitung richtig verstehe - die Anzeige von Straßennamen auf kurzen Fragmenten unterdrücken.
Nur leider meckert Maperitive, der Befehl sei unbekannt.

Weiß jemand eine Lösung?

Gruß
tippeltappel

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.

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

tippeltappel · 2011-11-25T11:03:34.000Z

@ 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

ajoessen · 2011-11-25T11:34:47.000Z

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

tippeltappel · 2011-11-25T12:43:26.000Z

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

tippeltappel · 2011-11-25T13:41:57.000Z

** … 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 · 2011-11-25T14:27:39.000Z

Hi

frage doch beim Meister nach ==> http://groups.google.com/group/maperitive

MfG
Achim

tippeltappel · 2011-11-25T17:23:57.000Z

Hab’s mal probiert.
Bin aber kein google-gruppen-fan.

Gruß
tt