Chiudi
Questo sito utilizza cookies. Chiudendo questa finestra acconsenti all'utilizzo dei cookies e approvi la nostra informativa sulla privacy.

Mkgmap e mappe Garmin da Openstreetmap (OSM)

Discussione in 'GPS e cartografia' iniziata da scratera, 17/1/13.

  1. scratera

    scratera Biker spectacularis

    Registrato:
    30/6/07
    Messaggi:
    22.676
    Bike:
    ...solo full...rigide...
    Mkgmap e mappe Garmin da Openstreetmap (OSM)


    E se cominciassimo a crearci le mappe da soli usando i dati grezzi di OSM.


    Prodursi le mappe partendo dai dati grezzi di OSM permette di adeguare il rendering (rappresentazione grafica) alle proprie esigenze ed eventualmente di ritagliare aree geografiche di interesse. Gli esempi di rendering che si trovano in rete danno un'idea delle infinite possibilità' offerte dai meccanismi che governano la trasformazione dei dati OSM in mappe.
    Questa guida descrive tali meccanismi soffermandosi sia sul processo di generazione delle mappe che sulle possibilità di manipolazione del risultato grafico finale.



    continua la lettura qua
    approfondisci qua

    scritto in collaborazione con @ataro @bis @FabryLorenz @sembola
    o voi che entrate armatevi di tanta pazienza...tanto tempo...tante prove...ma poi sarete soddisfatti...

    manuale di mkgmap
     

    Files Allegati:

    #1 scratera, 17/1/13
    Ultima modifica: 9/2/17
    • Mi piace Mi piace x 7
  2. scratera

    scratera Biker spectacularis

    Registrato:
    30/6/07
    Messaggi:
    22.676
    Bike:
    ...solo full...rigide...
    Come prima cosa il consiglio è di scaricarsi lo script di Marco Certelli da qua http://mce66.altervista.org/software.html
    Scompattarlo e aggiornarlo inserendo gli aggiornamenti dello Splitter e di Mkgmap all’interno della cartella Bin, ovvero caricare nello script tutte le cartelle e i file che troviamo all’interno dei due archivi.
    Crearsi una prima mappa inserendo una cartella con i due file di partenza, ovvero il file version e il file info allegati qua sotto in cui è scritta la versione e di andare ad utilizzare il file standard di Mkgmap ed un file TYP che propone lo script per creare una prima mappa e vedere come risulta e poi cominciare a giocare inserendo gli altri vari file di stile e solo quando e se si vuole abbandonare lo stile di default di Mkgmap andare a modificare il file info.
    Durante la compilazione avremmo una serie di errori ma la mappa viene compilata ugualmente

    [FONT=&quot]Alla fine otterremmo una mappa a cui sono stati applicati gli stili di default e avremmo un file style.TYP su cui cominciare a giocare, e quindi cominciare a crearci il nostro file TYP e cominciare ad aggiungere i vari comandi nei vari file poligons, lines, points, etc che cominciamo a compilare.
     

    Files Allegati:

    #2 scratera, 17/1/13
    Ultima modifica: 9/2/17
    • Mi piace Mi piace x 1
  3. spiri

    spiri Biker paradisiacus

    Registrato:
    17/4/10
    Messaggi:
    6.565
    Bike:
    liberazione, ettore, la meravigliosa, celestina
    gran bel lavoro! complimenti. ma quelli della garmin lo sanno ..... :smile::smile:
     
  4. marco-caco

    marco-caco Biker novus

    Registrato:
    3/10/07
    Messaggi:
    38
  5. scratera

    scratera Biker spectacularis

    Registrato:
    30/6/07
    Messaggi:
    22.676
    Bike:
    ...solo full...rigide...
    ...
    ...interessante anche questo...io stavo pensando ad una ripetizione del comando in maniera tale che trovata la prima sia obbligato a cercarne una seconda...ma in questa maniera mi sembra più lineare...o-o..
     
  6. marco-caco

    marco-caco Biker novus

    Registrato:
    3/10/07
    Messaggi:
    38
    Ma voi di lavoro fate i cartografi? Complimenti!
    E questo si può applicare anche alle mappe mtb/outdoor?
     
    • Mi piace Mi piace x 1
  7. Arma

    Arma Biker serius

    Registrato:
    30/9/04
    Messaggi:
    243
    Bike:
    Giant Trance
    Grandissimi!
    Immagino di essere in parte causa di questo tutorial viste le mie ultime richieste

    Grazie mille davvero!
     
  8. DoubleT

    DoubleT Biker superis

    Registrato:
    4/4/11
    Messaggi:
    347
    interessa avere per basecamp le mappe openmtbmap con le curve di livello (e questo è facile) in 3d, in modo da avere anche una traccia convertita da una rotta con l'altimetria? si può fare...
     
  9. DoubleT

    DoubleT Biker superis

    Registrato:
    4/4/11
    Messaggi:
    347
    'na roba così[​IMG]
     
  10. FabryLorenz

    FabryLorenz Biker velocissimus

    Registrato:
    28/7/06
    Messaggi:
    2.656
    Io porrei la questione in un thread apposito, qui si parla d'altro altrimenti diventa un altro topic da mille post e nessuno trova più quello che interessa... :spetteguless:
     
  11. ataro

    ataro Biker celestialis

    Registrato:
    16/4/09
    Messaggi:
    7.777
    Lo sanno, lo sanno. E' grazie alle mappe OSM che vendono i loro aggeggi a caro prezzo.
     
  12. DoubleT

    DoubleT Biker superis

    Registrato:
    4/4/11
    Messaggi:
    347
    come si fa, chi apre il thread...
     
  13. bis

    bis Biker augustus

    Registrato:
    29/12/08
    Messaggi:
    9.329
  14. ataro

    ataro Biker celestialis

    Registrato:
    16/4/09
    Messaggi:
    7.777
    Voglio dare un contributo alla comprensione dell'uso degli style di mkgmap.
    La cosa più difficile e meno documentata sono le relazioni.
    Partendo dal file relations dello style default di mkgmap ho costruito questo style, che è quello che uso attualmente.

    # -------------------------------------------------------------------
    # This is the mkgmap style file for applying rules on
    # OSM relations. Usually you will set tags on the
    # elements that make up the relation, and the tags will be
    # processed by the rules defined in the "points" or "lines" files.

    # Any line prefaced with # is a comment and will not be applied.
    # Each line is a rule, of the generalised format:
    # OSM_tag(s)_to_match [Garmin_type_code resolution]
    # See http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules
    # and http://wiki.openstreetmap.org/wiki/Mkgmap/help/Custom_styles
    # for more information.

    # Symbol ${} address relation tag and $() relation members tag

    # Boundary relations
    (type=boundary | type=multipolygon) & boundary=administrative & name=*
    {
    # Append the name of the boundary relation to the attribute
    # mkgmap:boundary_name of the member nodes recursively
    apply {
    set mkgmap:boundary_name='$(mkgmap:boundary_name):${name}' | '${name}';
    }

    # Prevent other relation processing
    delete type; delete boundary; delete name;
    }

    # Route relations
    type=route & route=* & (name=* | ref=*)
    {
    # If name is missing use ref as name
    add name='${ref}';

    # Append the type, name and ref of the route relation to the
    # attributes route_* of the member nodes recursively
    # (even to members of subrelations with role tag).
    apply {
    set route='$(route),${route}' | '${route}';
    set route_name='$(route_name),${name}' | '${name}';
    set route_ref='$(route_ref),${ref}' | '${ref}';

    # Style syntax test:
    # If subrelations with role tag exist, copy the name to them too
    set mkgmap:name='${name}';
    apply role=* {
    set route_name='$(route_name),${mkgmap:name}' | '${mkgmap:name}';
    }
    delete mkgmap:name;
    }

    # We could want to copy the route relation name to unnamed ways
    apply role=way { add name='${name}' }

    # Prevent other relation processing
    delete type; delete route; delete name; delete ref;
    }


    Ho inserito dei commenti che spiegano cosa produce il codice.
    Comunque faccio una descrizione passo-passo per i meno esperti.

    # Boundary relations

    la riga seguente cerca le le relazioni che hanno il tag type impostato a boundary oppure multipolygon, il tag boundary = ad administrative ed anche il tag name definito (se una relazione non possiede anche uno solo di questi tag non viene selezionata e nulla viene eseguito)
    (type=boundary | type=multipolygon) & boundary=administrative & name=*

    questa prima parentesi, con la corrispondente di chiusura, elenca il blocco delle azioni eseguite sui dati della relazione
    {

    il comando apply seguente ha la funzione di esplorare la lista dei membri della relazione (linee, poligoni e punti), applicando a ciascuno di essi le azioni che il suo blocco {} contiene.
    In questo caso viene estratto il nome della relazione, che viene concatenato a quello delle eventuali altre che hanno quel membro e che già sono state analizzate.
    # Append the name of the boundary relation to the attribute
    # mkgmap:boundary_name of the member nodes recursively
    apply {

    Vediamo come descrivendo il codice seguente.
    set mkgmap:boundary_name='$(mkgmap:boundary_name):${name}' | '${name}';

    La variabile mkgmap:boundary_name è un tag che è posseduto dal membro della relazione e non dalla relazione (i tag definiti dentro l'apply divengono proprietà dei membri della relazione). Il codice sostituibile $() opera sui tag dei membri della relazione e invece ${} su quelli della relazione (quindi su quelli assegnati fuori dall'apply).
    La concatenazione viene eseguita attaccando a destra della stringa finale (contenuta in mkgmap:boundary_name) in successione i nomi delle varie relazioni elaborate (contenuto in ${name}). La parte dopo l'or (il |) gestisce l'inizio della procedura, quando mkgmap:boundary_name non è ancora definita.

    Questo tag mkgmap:boundary_name lo potremo usare quando elaboreremo i comandi per i punti, le linee ed i poligoni (nei files points, lines e polygons)

    }

    Poi vengono cancellati i tag della relazione in modo che essa non possa essere processata ancora, ad esempio in un eventuale style collegato (io collego il mio al default di mkgmap)

    # Prevent other relation processing
    delete type; delete boundary; delete name;
    }

    A questo punto la rimanente parte del codice, che opera sulla relazione di tipo route, è più chiara:

    selezioniamo solo le relazioni di tipo route (type=route) e che hanno impostati i tag route (route=*) e o il nome o il ref
    # Route relations
    type=route & route=* & (name=* | ref=*)
    {
    qui lo dice il commento
    # If name is missing use ref as name
    add name='${ref}';

    # Append the type, name and ref of the route relation to the
    # attributes route_* of the member nodes recursively
    # (even to members of subrelations with role tag).
    apply {

    Vengono concatenati in tre tag assegnati ai membri (route, route_name e route_ref) i tipi di route, i nomi ed i ref delle relazioni successivamente elaborate.
    Anche questi tag li potremo poi usare nei comandi per punti, linee e poligoni (nei files points, lines e polygons).

    set route='$(route),${route}' | '${route}';
    set route_name='$(route_name),${name}' | '${name}';
    set route_ref='$(route_ref),${ref}' | '${ref}';

    La parte seguente è una prova, essa concatena il nome della relazione principale nel tag route_name dei membri della sottorelazione a patto che la sottorelazione abbia il tag role impostato (role=*) (apply role= è un comando non documentato).
    Per fare questo si crea un tag temporaneo (mkgmap:name), proprietà del membro della relazione principale.
    Tag temporaneo perché viene poi cancellato.
    # Style syntax test:
    # If subrelations with role tag exist, copy the name to them too
    set mkgmap:name='${name}';

    la variabile temporanea mkgmap:name prende il valore del nome della relazione principale, ma appartiene al membro della relazione principale

    L'apply seguente agisce solo sulle sottorelazioni (una relazione che è anche membro di un'altra relazione), ma solo su quelle che hanno il tag role impostato.
    apply role=* {
    set route_name='$(route_name),${mkgmap:name}' | '${mkgmap:name}';

    Nella concatenazione precedente route_name è un tag assegnato al membro (della sottorelazione), mentre abbiamo visto che mkgmap:name appartiene al membro della relazione principale, che in questo caso è la sottorelazione in esame e ${mkgmap:name} ne estrae il contenuto, che è il nome della relazione principale.
    Quindi il risultato è che alla fine il tag route_name dei membri della sottorelazione riceve la concatenazione dei nomi delle successive relazioni principali elaborate.

    }
    delete mkgmap:name;
    }

    Altra prova per gestire le sottorelazioni di tipo way.
    # We could want to copy the route relation name to unnamed ways
    apply role=way { add name='${name}' }

    I membri senza nome della sottorelazione ne prendono il nome (add crea name solo se già non esiste, mentre usando set si sovrascrive),
    infatti il tag name appartiene ai membri della sottorelazione, mentre ${name} estrae in questo caso il nome della sottorelazione

    # Prevent other relation processing
    delete type; delete route; delete name; delete ref;
    }




    Per usare i tag definiti sopra, si possono inserire comandi appositi nei files degli elementi.
    Ad esempio il file lines del default contiene

    # The following boundary styles are after the highway rules because ways
    # are frequently tagged with both and we want the highway to take priority.
    boundary=administrative { name '${mkgmap:boundary_name}' }
    boundary=administrative & admin_level<3 [0x1e resolution 16]
    ...........................

    che definisce il nome del boundary selezionato usando il valore del tag mkgmap:boundary_name, che è stato definito in relations.

    Mentre nel file lines del mio style uso gli altri tag definiti in relations:

    # Route

    Se una highway è anche una route, lo evidenzio attivando una apposita grafica (codice 0x10700).
    Il continue consente l'elaborazione successiva dell'elemento da parte di altra rules (come noto la presenza del campo [] termina l'elaborazione dell'elemento corrente).

    highway=* & route=* [0x10700 continue resolution 24]

    Le successive rules modificano il contenuto del tag name dell'elemento highway aggiungendo a destra i contenuti dei tag route_name e route_ref, anch'essi definiti in relations.

    # Set highway name to include the route_name if there is one
    highway=* & route_name=* { set name='${name} ${route_name}' | '${route_name}' }

    # Set highway name to include the route_ref if there is one
    highway=* & route_ref=* { set name='${name} ${route_ref}' | '${route_ref}' }
     
    • Mi piace Mi piace x 2
  15. scratera

    scratera Biker spectacularis

    Registrato:
    30/6/07
    Messaggi:
    22.676
    Bike:
    ...solo full...rigide...
  16. ataro

    ataro Biker celestialis

    Registrato:
    16/4/09
    Messaggi:
    7.777
    Ieri sera l'ho aggiornato ... non hai messo l'ultima versione. E poi, non capisco perché, non riesco a togliere quello spazio che compare in due punti nella stringa ${na me}, che dovrebbe essere ${name}, magari toglili tu.
    Aggiornato ancora ...
     
  17. ataro

    ataro Biker celestialis

    Registrato:
    16/4/09
    Messaggi:
    7.777
    Altre info che possono essere molto utili:

    # Grade 6-0
    highway=* & tracktype~'grade[0,6-9].*' { set name='G60 ${name}' | 'G60' }

    OSM riporta il tag tracktype=grade1 sino a grade5.
    La rule riportata controlla se esistono highway (highway=*) con tracktype impostato a grade0, grade6 sino a grade9 ed anche grade0xyz, grade6xx ..grade9yyz.
    Nel caso attacca a sinistra del nome la stringa G60 o, se il nome non esiste, lo definisce come G60.
     
    • Mi piace Mi piace x 1
  18. demon.box

    demon.box Biker urlandum

    Registrato:
    27/4/04
    Messaggi:
    581
    Bike:
    Canyon SpectrAL 015
    Il buon :il-saggi: Thorsten Kukuk (dalla mailing-list mkgmap-dev) mi ha fornito un altro suggerimento di sintassi che non sapevo esistesse:

    ref ~ '.*pippo.*' [0xXXX level Y]

    serve per esempio a cercare una stringa "pippo" se contenuta all'interno del tag (ref in questo caso).
    A me serviva e da solo mai ci sarei arrivato :omertà:
    In effetti le potenzialità nascoste :cucù: di questo sw sono mi sà davvero notevoli :celopiùg:<!-- / message --><!-- 300x250 nel primo post --><!-- / 300x250 nel primo post --><!-- 300x250 nell'ultimo post --><!-- / 300x250 nell'ultimo post --><!-- / message -->
     
  19. scratera

    scratera Biker spectacularis

    Registrato:
    30/6/07
    Messaggi:
    22.676
    Bike:
    ...solo full...rigide...
    ...non ho capito una cosa però...lo posizione dove..nel file in cui risiede l'elaborazione della relazione suppongo oppure anche in un altro file...faccio un esempio
    io ho i sentieri inseriti quindi nel file lines...come operatore ho ad esempio C.A.I.
    ...ora se inserisco la stringa
    operator ~ '.*C.A.I. | CAI | S.A.T. | SAT.*' [0x1151a resolution 24]
    nel file points verrà elaborata inserendo un punto sul sentiero ....:nunsacci:
     
  20. ataro

    ataro Biker celestialis

    Registrato:
    16/4/09
    Messaggi:
    7.777
    Nel file relations originale c'è un commento che contiene
    node role ~ '(start_|end_)stop'
    che mi fa pensare che quello che vuoi fare deve essere scritto (ma non ho mai provato così)
    operator ~ '.*(C.A.I.|CAI|S.A.T.|SAT).*' [0x1151a resolution 24]
    facendo in modo che il comando sia attivato quando un elemento (punto,linea,poligono e forse relazione) possiede il tag operator impostato a
    xxxC.A.I.xxx oppure xxCAIxx, xxS.A.T.xx o infine xxxSATxxxx, nel caso viene generato l'elemento corrispondente Garmin di codice e zoom specificati.
    Ma non lo puoi mettere in un blocco action del file relations.
    Se lo metti nel file relations l'elemento è una relazione. Ho provato a mettere per prova un blocco di generazione [] nel file relations, ma ho usato
    un hex che non avevo nel typ. Non conosco quello che genera, anche se mkgmap non ha dato errore (ho usato come hex sia 0x00 che 0x30)
     
Sto caricando...

Condividi questa Pagina