OSM Cartografia con sentieristica x GARMIN GRATIS!CONTRIBUISCI!scarica allegati!

[bis]

Oggi ho in mente qualche esperimento java su linux.
Prima di perder tempo pero', vorrei un ulteriore chiarimento.

Se ho capito bene, extremecarver cambia con una certa frequenza i file implicati nelle generazione delle mappe.

Ora, anche fosse, presumendo che i nomi abbinati ai vari oggetti, non cambino, stavo considerando che nella peggiore delle ipotesi, potrei editare direttamente i file di testo .prj per sistemare le evenutali incongruenze.

Per capirci. Attualmente, il poligono vineyard e' definito come tipo 0x30, con una lista di linee che ne definiscono le caratteristiche grafiche.
Nel caso cambiasse l'hex abbinato a questo nome, o modifico l'hex nel mio file, o modifico tutto il resto nel suo - basta un cut&paste.

Prodotti MTB scontati

 

[bis]

lo splitter genera la stessa eccezione anche se eseguito su ubuntu.
Ora sto scaricando l'italia e poi riprovo tutto (su ubuntu, tanto e' java).

 

[misterGI]

Dopo aver scritto che ha processato 5.000.000 di nodi, mi escono 10 righe per una exception di tipo ArrayIndexOutOfBounds.

ciao bis,
poco tempo fa ho usato lo splitter e altri programmi vari per crearmi delle curve di livello (http://www.mtb-forum.it/community/forum/showthread.php?t=216051).
Pure io, in alcuni casi, ho avuto degli errori con lo splitter, del tipo ArrayIndexOutOfBounds. Nel mio caso l'errore veniva fuori se editavo con JOSM i files .osm creati da phyghtmap. Sono giunto alla conclusione che ci sia una qualche incompatibilità tra alcuni formati di dati OSM e le ultime versioni dello splitter. Infatti usando uno plitter più vecchio (la versione 161 al posto della 185) non ho più avuto questi errori.
Non so se il tuo caso sia lo stesso del mio, ma spero di averti dato una dritta...
ps: io uso il tutto su Linux RedHat.

 

[bis]

ciao bis,
poco tempo fa ho usato lo splitter e altri programmi vari per crearmi delle curve di livello (http://www.mtb-forum.it/community/forum/showthread.php?t=216051).
Pure io, in alcuni casi, ho avuto degli errori con lo splitter, del tipo ArrayIndexOutOfBounds. Nel mio caso l'errore veniva fuori se editavo con JOSM i files .osm creati da phyghtmap. Sono giunto alla conclusione che ci sia una qualche incompatibilità tra alcuni formati di dati OSM e le ultime versioni dello splitter. Infatti usando uno plitter più vecchio (la versione 161 al posto della 185) non ho più avuto questi errori.
Non so se il tuo caso sia lo stesso del mio, ma spero di averti dato una dritta...
ps: io uso il tutto su Linux RedHat.

Ciao e grazie per l'info.
Comunque, ho scaricato l'italia e lo splitter ha superato il problema che vedevo con la lombardia.
Ora ha prodotto i tanti .gz e sta facendo il passo 1 di 1.
Lo sto facendo girare su ubuntu visto che e' sicuramente piu' veloce di windows, anche se in questo caso e' tutta questione di cpu e memoria e il mio pc non brilla

 

[bis]

ps: io uso il tutto su Linux RedHat.

Sei per caso riuscito a far girare MapTk Su linux?

 

[misterGI]

Sei per caso riuscito a far girare MapTk Su linux?

no, dovendo fare solo le curve di livello ho usato phyghtmap (o qualche prova con Srtm2Osm), lo splitter e mkgmap.
Una volta creati i files img ho poi usato MapsetToolkit per creare le mappe per Basecamp, passandogli anche un file .typ, ma quest'ultima cosa l'ho fatta su windows

 

[ataro]

Ho appena letto sul suo sito che è uscita una nuova versione di Maptk, la 3.1.2, che supporta linux solo tramite ambiente Pyton. Hai provato con quella versione?

 

[bis]

Ho appena letto sul suo sito che è uscita una nuova versione di Maptk, la 3.1.2, che supporta linux solo tramite ambiente Pyton. Hai provato con quella versione?

Sto usando la beta05.
Ora vado sul sito a dare un'occhiata.

Comunque, per linux, mi e' bastato invertire le \ windows in / ala unix e prestare attenzione alla case sensitiveness, che tutto funziona.

Ora sto rigenerando usando lo stile master.
Se e' decente, riparto da quello con eventualmente qualche cut&paste dal wideit che ho modificato.
Se il risultato non fosse all'altezza, passo al piano di contingency; scrordarmi di fare tutto in casa e adattare il wideit nel caso extremecarver lo modifichi.

 

[bis]

Ho appena letto sul suo sito che è uscita una nuova versione di Maptk, la 3.1.2, che supporta linux solo tramite ambiente Pyton. Hai provato con quella versione?

Scusa ... abbaglio, parlavi di maptk ...
Ora verifico, anche se avevo scaricato la versione per ubuntu.

 

[bis]

Ho appena letto sul suo sito che è uscita una nuova versione di Maptk, la 3.1.2, che supporta linux solo tramite ambiente Pyton. Hai provato con quella versione?

Evvai questo funziona!!!
Grazie.

 

[bis]

Fatemi capire una cosa.
Nella generazione dei .img (non imagesup.img), mkgmap, usa soli i file stile, non il .TYP, giusto ?

 

[misterGI]

Fatemi capire una cosa.
Nella generazione dei .img (non imagesup.img), mkgmap, usa soli i file stile, non il .TYP, giusto ?

direi di si. Il typ l'ho usato solo con MapsetToolkit, mentre con mkgmap ho usato lo stile e il file .args

 

[ataro]

direi di si. Il typ l'ho usato solo con MapsetToolkit, mentre con mkgmap ho usato lo stile e il file .args

Confermo.

 

[scratera]

Se ho capito bene, extremecarver cambia con una certa frequenza i file implicati nelle generazione delle mappe.

...nulla ti vieta una volta che trovi il tuo o modifichi il suo di usare sempre quello for ever...
...mce66 però durante la creazione preleva anche il file.typ e lo rinomina affiancandolo ai file.img che va a creare...

 

[sembola]

...nulla ti vieta una volta che trovi il tuo o modifichi il suo di usare sempre quello for ever...

Te lo vieta il fatto che quando ExtremeCarver cambia le definizioni il file typ tanto amorevolmente modificato non riesce più a visualizzare correttamente alcuni elementi...

 

[scratera]

Te lo vieta il fatto che quando ExtremeCarver cambia le definizioni il file typ tanto amorevolmente modificato non riesce più a visualizzare correttamente alcuni elementi...

...si ma non è il mio caso o il nostro caso in quanto partiamo dai dati grezzi e usando il file.typ e gli stili relativi la mappa la creiamo noi...ti faccio un esempio io nelle mie visualizzo tutt'ora le strade con accesso vietato che ExtremeCarver ha tolto qualche mese fa...........usando per l'appunto dei sui vecchi stili e fileTyp relativo....

 

[bis]

...nulla ti vieta una volta che trovi il tuo o modifichi il suo di usare sempre quello for ever...
...mce66 però durante la creazione preleva anche il file.typ e lo rinomina affiancandolo ai file.img che va a creare...

Secondo me lo usa solo alla fine del processo quando deve generare imagesup.img.
Tra gli stili c'e' masterstyle, mentre nei tpy c'e' master.tpy.
Il primo e' un parametro di mkgmap, il secondo no.
Peraltro questo mi parrebbe pure sensato, visto che il .typ non aggiunge nulla alla generazione dei .img.

 

[bis]

Te lo vieta il fatto che quando ExtremeCarver cambia le definizioni il file typ tanto amorevolmente modificato non riesce più a visualizzare correttamente alcuni elementi...

Si, hai ragione.
Pero', come scrivevo nel post, il costo di aggiornare i nuovi wideit.typ che produce, con le modifiche che ho nel mio, non mi pare eccessivo, visto che con cut&paste sul .prj si va veloci.
Conto peraltro che non s'inventi di cambiare il nome alle cose.
Se mi cambia l'esadecimale di park, me ne accogo ma se mi cambia park con area verde, faccio piu' fatica.

 

[bis]

...si ma non è il mio caso o il nostro caso in quanto partiamo dai dati grezzi e usando il file.typ e gli stili relativi la mappa la creiamo noi...ti faccio un esempio io nelle mie visualizzo tutt'ora le strade con accesso vietato che ExtremeCarver ha tolto qualche mese fa...........usando per l'appunto dei sui vecchi stili e fileTyp relativo....

Per farlo, hai patchato mkgmap?

 

[ataro]

@ bis:

direi di si. Il typ l'ho usato solo con MapsetToolkit, mentre con mkgmap ho usato lo stile e il file .args

Il typ lo usa garmin per cambiare la grafica di default della mappa e non viene usato da mkgmap

Te lo vieta il fatto che quando ExtremeCarver cambia le definizioni il file typ tanto amorevolmente modificato non riesce più a visualizzare correttamente alcuni elementi...

e questa cosa se ora non ti spaventa, diventerà presto molto tediosa

...si ma non è il mio caso o il nostro caso in quanto partiamo dai dati grezzi e usando il file.typ e gli stili relativi la mappa la creiamo noi...ti faccio un esempio io nelle mie visualizzo tutt'ora le strade con accesso vietato che ExtremeCarver ha tolto qualche mese fa...........usando per l'appunto dei sui vecchi stili e fileTyp relativo....

questa è la strada per avere molto e combattere poco

Secondo me lo usa solo alla fine del processo quando deve generare imagesup.img.
Tra gli stili c'e' masterstyle, mentre nei tpy c'e' master.tpy.
Il primo e' un parametro di mkgmap, il secondo no.
Peraltro questo mi parrebbe pure sensato, visto che il .typ non aggiunge nulla alla generazione dei .img.

confermo

Si, hai ragione.
Pero', come scrivevo nel post, il costo di aggiornare i nuovi wideit.typ che produce, con le modifiche che ho nel mio, non mi pare eccessivo, visto che con cut&paste sul .prj si va veloci.
Conto peraltro che non s'inventi di cambiare il nome alle cose.
Se mi cambia l'esadecimale di park, me ne accogo ma se mi cambia park con area verde, faccio piu' fatica.

è successo.

Come ti hanno suggerito, la strada giusta non è quella di adattare il tuo typ alle omtb, ma quella di produrti le tue di mappe.