[Gfoss] [Qgis-developer] Is fastest (not shortest) path routing possible in PyQGIS

giulianc51 giulianc51 a gmail.com
Lun 21 Lug 2014 18:26:06 CEST


Il giorno Mon, 21 Jul 2014 12:30:03 +0200
giulianc51 <giulianc51 a gmail.com> ha scritto:


> Il giorno Mon, 21 Jul 2014 11:20:52 +0200
> "G. Allegri" <giohappy a gmail.com> ha scritto:
> ...

intanto non so se quì è il posto giusto per porre domande
sull'argomento o se è meglio in pvt (visto che la lista developer è per
me off limits :-); provo con una prima serie, pronto a scusarmi e
ritirarmi in caso di mancato gradimento :-)


> > .......
> > il cookbook ha una sezione dedicata a questo argomento:
> > http://docs.qgis.org/testing/en/docs/pyqgis_developer_cookbook/network_analysis.html
> 
> grazie, a prima vista si è evoluto rispetto alla versione che avevo
> visto qualche tempo; bene, darò uno sguardo con attenzione;

dando uno sguardo mi sono chiesto:

1) ho sempre inteso i grafi come studio topologico (nodi e relazioni
_archi_) senza necessità di alcuna metrica: mi chiedo quindi la
motivazione dell'uso del CRS come elemento mandatory del builder? (1)

2) il metodo "properter" sembra non avere opzioni settabili, qual'è
l'esatta sua funzione?

3) gli algoritmi di Shortest Path, fra cui il Dijkstra, operano su pesi
applicati agli archi, non necessariamente legati alla distanza; ad es.
se il peso affidato agli archi è il tempo ecco che il _shortest_
diventa il _fastest_ come chiedeva Anita; dalla sua domanda arguisco che
non sia così, cosa mi sfugge?

hai voglia di buttare qualche raggio di luce in questa landa
oscura ? :-)

 
> > giovanni
 
grazie, ciao,
giuliano
 
(1) è chiaro che se faccio analisi basate su distanze fisiche ho
bisogno del crs e con esso della metrica euclidea, ma se volessi fare
analisi basate ad es. sui costi la metrica è del tutto diversa; quindi
perchè questo fondamento sul crs/metrica euclidea visto che questa si
porta dietro la disuguaglianza triangolare?


Maggiori informazioni sulla lista Gfoss