Indirizzo non precisissimo quando si calcola il percorso

[Lychfindel]

Attualmente invece di calcolare il percorso esatto tra due indirizzi, ovvero:
indirizzo A -> indirizzo B
estraiamo dall'indirizzo il nodo più vicino, quindi ora abbiamo:
nodo più vicino a indirizzo A -> nodo più vicino a indirizzo B

[lucatastrophe]

si potrebbe aggiungere una riga che il punto con la posizione originale (come facciamo quando cerchiamo solo l'indirizzo) ovviamente verrebbe una riga "a cazzo", ma almeno parte dal punto giusto!

[Lychfindel]

Nell'shp dei civici ogni civico è una linea che collega la porta di strada alla casa, quindi secondo me la soluzione "più giusta" sarebbe trovare dallo shp file dei civici l'intersezione con la strada, aggiungere là un nodo fittizio e calcolare il percorso, oppure addirittura aggiungere direttamente l'edge del civico. Per fare ciò bisognerebbe dividere l'edge della strada in due aggiungendo un nodo in mezzo, ma dalla documentazione di networkx non capisco come fare questo passaggio

[freerafiki]

Concordo con @Lychfindel . Anche nel fatto che dalla documentazione di networkx non si capisce come fare la divisione di un arco.
Una soluzione piu semplice che potrebbe temporaneamente essere adottata sarebbe:
1 - ritornare da civico2coord entrambe le cose, la coordinata del civico E il nodo piu vicino
2 - creare un nuovo nodo G.add_node(coord_civico) e creare un arco da quel nodo al nodo piu vicino G.add_edge(coord_civico, nodo_piu_vicino, weight=D ) dove D=dist2D(coord_civico, nodo_piu_vicino) sarebbe una semplice distanza euclidea. O forse D puo anche essere 0 se non vogliamo influenzare i calcoli. Non sarebbe perfetto come l'shp ma probabilmente avrebbe una "diagonale", ma potrebbe funzionare e risparmiarci casini.

Il problema e pero, che dopo la ricerca bisogna rimuovere l'edge (altrimenti ne abbiamo milioni dopo un po') e qua bisogna stare attenti, non so bene quando farlo nel codice. Forse salvare una variabile con i archi_temporanei e ogni volta lanciare [G.remove_edge(arco_tmp) for arco_tmp in archi_temporanei]

[Lychfindel]

Io proporrei questa scaletta:

1. proviamo ad aggiungere tutti i nodi dei civici e vediamo se facendo ciò la ricerca del percorso ottimo viene rallentata di tanto
   Nel caso venga rallentato:
2. creare una copia del grafo su cui lavorare da ora in poi per la sessione di ricerca
3. ritornare il civico, l'arco del civico e l'arco orginario su cui si collegherebbe l'arco del civico
4. creare un nuovo nodo nel punto di intersezione e un nuovo arco dal civico al punto di intersezione
5. creare due nuovi archi che colleghino i nodi dell'arco originario con il nuovo nodo creato al punto 4 (sovrascrivendo le informazioni di forma dall'arco originario)
6. eliminare l'arco originario
7. effettuare la ricerca sul grafo temporaneo
   Ovviamente bisogna capire dal punto di vista computazionale cosa comporta tutto ciò

[lucatastrophe]

Risultati del test sul grafo con tutti i nodi che mandano agli indirizzi:
santa marghe
san basegio
ci ho messo 0.9164201159996992 a calcolare la posizione degli indirizzi
ci ho messo 0.006171320999783347 a calcolare la strada
ci ho messo 0.9068670179999572 a trovare il nodo di partenza con il grafo pesante
ci ho messo 0.04267677200004982 a calcolare la strada con il grafo pesante

sant'elena
ple roma
ci ho messo 0.7665785069998492 a calcolare la posizione degli indirizzi
ci ho messo 0.08762148699997852 a calcolare la strada
ci ho messo 1.4929195869999603 a trovare il nodo di partenza con il grafo pesante
ci ho messo 0.7370723660001204 a calcolare la strada con il grafo pesante

Celestia
Tre Archi
ci ho messo 0.7061049520002598 a calcolare la posizione degli indirizzi
ci ho messo 0.06817397599979813 a calcolare la strada
ci ho messo 1.107265715000267 a trovare il nodo di partenza con il grafo pesante
ci ho messo 0.3637642749999941 a calcolare la strada con il grafo pesante

Sembra che il grafo abbia un impatto contenuto sulla ricerca del nodo (questo si migliora con la proposta #30, visto che potremo direttamente prenderci il nodo di inserzione dal db, invece di cercare il nodo più vicino).
Ha invece un impatto pesante sulla ricerca del percorso (il tempo aumenta di 5-10 volte). Ma siamo su numeri molto piccoli, qualche decimo di secondo probabilmente possiamo tollerarlo.

[lucatastrophe]

Questa è stata risolta per quanto riguarda la precisione degli indirizzi. è stata inserita l'aggiunta dinamica nel grafo acqueo, da considerare anche, eventualmente per quello terrestre, se dovessimo decidere di farlo riapriremo una issue.