OSM Composer V0.81 mit neuem Wizard

Gutes Timing. :slight_smile: Es gibt in den 0.8 Versionen einen Bug, der dafĂŒr sorgt daß nach dem API-Download die Routen nicht richtig eingelesen werden. Den habe ich gestern entdeckt und behoben. In 0.82 ist das wieder in Ordnung.

Habe den API-Download in letzter Zeit wohl etwas vernachlĂ€ssigt, dafĂŒr bekommt er in 0.82 ein sehr hĂŒbsches neues Feature.

danke fĂŒr’s Feedback

          Nop

HI,
Super freue mich schon darauf. Gibt es irgendwo auch eine Liste von diesen Garmin ID’s hab schon gegoogelt bin aber nicht fĂŒndig geworden.
Na ja hab auch noch zwei Objekte mit eingebaut die auch gerendert werden, falls Du Lust hast kannst die ja mit einbauen. Wie gesagt da ich nicht genau weiß ob dort Garmin was anderes belegt hat ist das auch nur ein Versuch, in MapSource wird es jedenfalls angezeigt. Das meiste davon hab ich aus OSM genommen und der grĂŒne Back ist ja offizielles Wandersymbol.




So nun noch schönes WE Dein Progi ist wirklich SUPER Gruß AlterSachse

HI Nop,
muss noch mal stören. Habe jetzt in Ver. 081 die gleiche Regel fĂŒr den Bunker (pillbox) erstellt wie unter der 080rc1 und der 080 aber hier wird er nicht gerendert.
Hab ich einen Fehler gemacht oder an was liegt das nun. Die Bunker, Schöberlinie, sind in unserer Region halt ein beliebtes Wanderziel deshalb hab ich sie mit aufgenommen.
Gruß

<<01.02. – Sorry, hab alles noch mal neu gemacht in Ver. 081 denn ich hatte scheinbar irgendwo einen Tippfehler drin. Jedenfalls jetzt geht es wieder. Der Bunker wird wieder angezeigt und auch in TTQV bekommt dieser Punkt den Namen “Man_made place” zugewiesen. >>

Hallo Nop,

ich hab da mal ein Problem zur Unterscheidung von FlÀchen und Wegen im Composer. Wie unterschiedest du das? Bei mir gibt es Probleme bei Tags, die sowohl als Weg als auch als FlÀche vorkommen. Hier wird nur der Umriss gezeichnet, nicht aber der FlÀcheninhalt. Die FlÀche wird also als Weg betrachtet, obwohl sie korrekt getaggt ist.

Weiterhin wÀre es noch ein nettes Feature, wenn man FlÀchen einen Rahmen geben könnte.

Es ist ein grunsĂ€tzliches Problem in OSM, daß man FlĂ€chen und Wege nicht unterscheiden kann. HĂ€ufig wird dann die KrĂŒcke “area=yes” dafĂŒr hergenommen.

Ich mache dann fĂŒr den weniger hĂ€ufigen Falle eine Ersetzungsregel, die es auf ein eigenes Tag ummapped. Z.B. das unheimlich schlechte Tag highway=pedestrian wird in Kombination mit area=yes zu highway=pedestrian_area und das kann man dann in Ruhe weiterverarbeiten.

Einen Rand um eine FlÀche kannst Du ebenfalls mit einer Ersetzungsregel erzeugen.

bye
Nop

Ist doch egtl. recht einfach zu erkennen. Wenn der erste Node gleich dem letzten Node ist, ist es eine FlÀche, ansonsten ein Weg. Oder ist das zu einfach?

Das ĂŒber eine ersetzung zu machen geht nicht, da wie gesagt die Tag identisch sind. In meinem Fall geht es um man_made=pier.

Kannst du mir einen kleinen Hinweis geben, wie ich den Rand ĂŒber eine Ersetzung hinbekomme
ich steh gerade etwas auf dem Schlauch.

Ja. Die Annahme fĂŒhrte zum Verschwinden aller Kreisverkehre. :slight_smile:

FĂŒr einen Rand schau Dir mal “Naturschutzgebiet umranden” in den Standardregeln von Composer an.

bye

    Nop

Ok
du hast recht
an die Kreisverkehre hab ich garnicht gedacht
(mag ich als Radfahrer aber auch ĂŒberhaupt nicht, könnten also ruhig verschwinden :wink: )

Ich hab mir eben auch mal das Routing angeschaut und werde in nÀchster Zeit mal etwas damit rumspielen


Was mir gleich “störend” ins Auge gestoßen ist, sind die Bezeichnungen bei Roadclass. Auf der einen Seite sind das die Bezeichnungen, wie sie Garmin verwendet, auf der anderen Seite geben sie ja nur die PrioritĂ€t an. Ich finde es etwas verwirrend, wenn ich einer Bundesstraße bspw. das Attribut Feldweg anhefte und dem befestigten Radweg das Attribut Autobahn.

WÀre es nicht besser, die DropDownBox-EintrÀge anhand der PrioritÀt zu benennen?

Mach einen Vorschlag.

Hallo Nop,

kaum mach ich mal ne kurze Pause bei OSM, schon gibt es eine neue Composer Version.
Der neue Wizard ist echt ein Hit, ich hab auf Anhieb einige Fehler gefunden, nach denen ich bisher erfolglos gesucht hatte.
Auch die Möglichkeit der FlĂ€chenicons ist super, damit spare ich mir fast 30% meiner Ersetzungen und ĂŒbersichtlicher ist es auch noch.
Meine hunderten Ersetzungen waren schon recht verwirrend, mit dem Wizard wird es nun um einiges einfacher.
Ich nutze auch gleich die direkte Bearbeitung aus dem Wizard heraus, nur das EinfĂŒgen neuer Regeln mache ich noch auf die alte Art.
Das Wizard-Konzept ist sicher noch weiter ausbaufÀhig, z.B. Anzeige von Regeln die vom Tagfilter neutralisiert werden.

Was macht das neue Flag “RoutingfĂ€hige Karte” bei den Garmin-Einstellungen eigentlich genau?
Zum Splitter habe ich noch eine Frage bezĂŒglich Routing.
Kannst du eine Überlappung um eine OSM-Einheit einbauen, damit mkgmap getrennte Wege wieder zusammenfĂŒgen kann.
Ich denke, ohne diese Überlappung wird ein durchgehendes Routing ĂŒber Kachelgrenzen hinweg nicht machbar sein.
Bei den Durchreich-Tags sind bridge, tunnel usw. gesetzt, das wird fĂŒr’s Routing sicher noch deutlich erweitert werden.
Wenn ich eine Liste der notwendigen TAGs erprobt habe, kann ich sie ja direkt in die Composer-Anleitung reinschreiben.

Walter

@walter
Das Flag “RoutingfĂ€hige Karte” schaltet bei den Renderregeln die Routingeinstellungen frei und setzt beim mkgmap-Aufruf die beiden zusĂ€tzlichen Parameter.
Ansonsten solche Listen von Tags, die man durchlassen muss, damit routing, Adresssuche, generate-sea und was auch immer gut funktionieren sollte man auf einer extra Unterseite vom Composer sammeln. Quasi eine KnowHow-Sammlung zu Einstellungen. Dort könnte man dann auch seine Presets verlinken.

@nop
Wie wÀre es mit höchste, hohe, normale oder mittelere, geringe und geringste PrioritÀt?
Hast du die Geschwindigkeiten frei gewĂ€hlt, oder woher kommen die Werte, die du angegeben hast? Wenn sie frei gewĂ€hlt sind wĂ€re ich hier auch fĂŒr eine Ă€hnliche Steigerung, nur halt von langsam bis schnell.

Hallo Henning,

vielen Dank, jetzt hab ich’s kapiert (war wohl zu einfach). Dann werde ich mal meine Renderregeln auf RoutingfĂ€higkeit erweitern.
Bin schon gespannt, wie das Ergebnis im Vergleich zu meinen frĂŒheren Bastelversuchen abschneidet.
Ich denke, wir sind hier auf dem richtigen Weg, dass mit dem Composer bald uneingeschrÀnkt routingfÀhige PlÀne erzeugt werden können.

Leider kann ich derzeit noch nicht auf den manuellen mkgmap Aufruf verzichten, da der Parameter --gmapsupp ja nicht dynamisch ĂŒbergeben werden kann.
Hoffentlich fÀllt mir dazu noch eine Lösung ein, die auf einfache Art implementierbar wÀre.

Zum Thema Routingprio wĂŒrde ich folgende Bezeichnung vorschlagen:
0 (Wohngebiet, Feldweg)
1 (Kreisverkehr)


Damit ist die interne Garmin-Prio fĂŒr Profis deutlich erkennbar (0 bis 4) und der Laie kann trotzdem ohne Nachschlagewerk seine Wege optimal zuordnen.
Ich verstehe dich (@Henning) jedoch nicht, warum du “falsche” Prios zuordnen möchtest. Das wĂŒrde doch nur zu unplausiblen RoutingvorschlĂ€gen des GerĂ€tes fĂŒhren.
Im cGPSmapper Manual auf Seite 53 kann ĂŒber Road class und Speed attribute nachgelesen werden.
Es gibt auch einige Infos in diesem und anderen Foren ĂŒber die entsprechenden mkgmap Parameter.

Walter

Noch eine Frage zu den Ersetzungen.
Wenn ich einer Straße je nach maxspeed eine bestimmte road_speed zuordnen möchte (z.B. >20 bis <=40km/h),
dann kann ich wohl nicht einfach schreiben: Bedingung maxspeed >20 & <41.
Als Lösung könnte ich mir vorstellen: Bedingung maxspeed entspricht 25|30|35|40.
Was ist von dieser Lösung zu halten? Welche Speed-Limits gibt es in USA und England?

Das geht noch einfacher/komplizierter. Das sind echte RegulĂ€re AudrĂŒcke, da kannst Du Dir sicher ein wasserdichtes Suchmuster fĂŒr bauen.
http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html

bye
Nop

Hallo Walter,
evtl. sitze ich auch einem MissverstĂ€ndis auf. Ich will das Routing fĂŒrs Radfahren optimieren. Die Radwege etc. sollen also höchste PrioritĂ€t haben, dann residentials und so und als letztes Bundesstraßen
Autobahnen und Kraftstraßen fliegen raus


BTW: ich glaub im Naviboard hat extremcarver auch mal von mehr routingfĂ€higen “Layern” gesprochen
wenn ich mal etwas mehr zeit hab, such ich mal, ob ich das nochmal finde.

Hallo Nop,

ich habe nur Range fĂŒr char gefungen, nicht fĂŒr Zahlen. Werde daher beim “entspricht” bleiben (ist ja kein großes Problem)
Hast du schon ĂŒber meine Idee zum Splitter in Posting #31 nachgedacht?

Hallo Henning,

fĂŒr Radwege hat das Garmin und mkgmap wohl eigene Regeln. Da bin ich nicht so der Experte.
Wichtig sind hier natĂŒrlich TAGs wie z.B. bicycle = yes|no

Was ist eine OSM-Einheit? Momentan teilt Composer ganz exakt. Es wĂ€re halt wichtig zu wissen, worauf man dabei achten muß, damit ein ĂŒbergreifendes Routing möglich ist. Da hab ich leider keinen Plan.

bye
Nop

Hallo Nop,

ich könnte mir vorstellen, dass es nicht sehr kompliziert sein darf, ein File so zu splitten, dass es wieder zusammengesetzt werden kann.
Es wĂŒrde sonst einfach zu viel Speicherbedarf fĂŒr Zusatzinfo anfallen.
Daher ist meine Theorie auch bewusst trivial. Ich möchte der Einfachheit halber mal ein 1-dimensionales Beispiel hernehmen.
Ein Weg geht von Koordinate 27 bis 183 und wird an der Stelle 100 getrennt.
Dann gibt es 2 WegstĂŒcke, eines von 27-100 und eines von 101 bis 183.
Diese beiden Wege haben eine LĂŒcke von 100 bis 101 und können daher kaum jemals wieder sauber verbunden werden (zumindest bei 2-dimensionalen Objekten).
Wenn wir jedoch die beiden Wege um exakt 1 “Pixel” ĂŒberlappen lassen (also von 27-100 und von 100-183),
dann wĂ€re es möglich, diese beiden (jetzt ĂŒberlappenden) Wege am gemeinsamen Schnittpunkt wieder zu verbinden.
Da ich im Plan ab und zu hauchdĂŒnne Trennlinien erkennen kann, nehme ich an, dass der Composer derzeit keine Überlappungen vorsieht.
Die kleinste Einheit bei OSM ist meines Wissens nach 0,0000001 Grad. Das meinte ich mit OSM-Einheit. (entspricht wohl ungefĂ€hr 1cm, ist aber fĂŒr’s Splitting jetzt nicht relevant)
Wenn jetzt die gesplitteten Elemente sich um diesen Wert ĂŒberlappen wĂŒrden, wĂ€re es möglich, solche Elemente wieder zu verbinden.
Das ist einfach die Idee, die ich habe. Garantie auf Richtigkeit habe ich keine, aber ich hoffe jedenfalls sehr, dass ich damit richtig liege.

Walter

Derzeit gibt es keine LĂŒcken. Die Trennlinie an der geschnitten wird hat keine Breite und die Schnittpunkte von beiden Seiten haben die gleichen Koordinaten (abgesehen von Rundungsfehlern). Die erforderlichen Regeln sind irgendwo in mkgmap eingebaut. Kennt die jemand?

bye
Nop