Costruire un poligono su un'area raggiungibile

Attualmente sto lavorando nel campo delle isocrone e degli algoritmi sottostanti. Ciò che ora causa problemi non è il calcolo se lo stesso isochrone, ma la visualizzazione dei risultati.
Il risultato del mio algoritmo isochrone sono punti e spigoli. In effetti ho una soluzione funzionante, ma per 3873 edge e per 1529 nodi le cose sembrano richiedere per sempre (circa 2,0 secondi sul mio laptop Lenovo T440s che contiene una CPU Core i7 2015 e un SSD piuttosto veloce). Invece di secondi voglio qualcosa di più simile a msec :-).

Forse qualcuno può aiutarmi a ridurre il tempo di calcolo necessario per costruire i poligoni che visualizzano le aree raggiungibili.

Ma aspetta ... prima le prime cose!
Ecco una visualizzazione dei bordi che sono il risultato del calcolo del mio isochrone: questi bordi sono memorizzati in una tabella del database PostGIS e sono semplici stringhe di linea.

Quello che voglio mostrare all'utente è simile al seguente: Nota le aree disconnesse nell'estremo sud e molto ad est dell'immagine. Questi dovrebbero essere disegnati come aree separate (quindi non è consentita la fusione qui :-))

Attualmente sto usando questa query:

SELECT ST_AsGeoJson(St_Transform(ST_Multi(ST_Collect(polygons)), 4326)) AS coverage FROM (
    SELECT ST_MakePolygon(ST_ExteriorRing(ST_GeometryN(segments, generate_series(1, ST_NumGeometries(segments))))) AS polygons FROM (
        SELECT ST_Union(ST_Buffer("GEOMETRY", 20, 'quad_segs=2')) AS segments FROM my_edges AS a
    ) AS b
) AS c

Ho già fatto alcuni esperimenti e ho anche letto molta documentazione, ma non riesco proprio a trovare una soluzione migliore.
Ai miei occhi il grosso problema è l'uso di ST_Union (come indicato nei documenti questa funzione può essere lenta). La cosa molto interessante è che la sua sostituzione con ST_Collect sembra rallentare il calcolo ST_Buffer in modo che la query nel complesso richieda ancora più tempo, sebbene non riempia le aree tra i bordi (crea solo un buffer attorno alle linee ):

SELECT ST_AsGeoJson(St_Transform(ST_Multi(ST_Collect(polygons)), 4326)) AS coverage FROM (
    SELECT ST_Buffer(ST_Collect(ST_LineMerge("GEOMETRY")), 20, 'quad_segs=2') AS polygons FROM my_edges AS a
) AS b

Questo richiede circa 3,8 secondi sul mio sistema (quindi quasi il doppio del tempo). La mia prima conclusione su questo piccolo benchmark è che ST_Buffer diventa inaspettatamente lento quando si tratta di MultiLineStrings (anche più lento di quando si creano buffer per ogni linea e si uniscono i buffer - che ai miei occhi è solo strano)

Ho anche provato a usare le forme alfa (usando l'implementazione di pgRouting), ma poiché non esiste un valore alfa da impostare (e in effetti non vorrei davvero ora quale valore impostare tale valore) ottengo solo un grande poligono ( quindi perderei le regioni del sud e dell'est come regioni separate che non è quello che voglio).
Anche ST_Polygonize (che è stata la prima cosa che mi è venuta in mente) non ha prodotto risultati utilizzabili, ma forse mi sono perso qualcosa qui ...

Esiste un modo migliore per creare l'area mostrata in PostGIS? Forse anche usando il codice java (jts) o il codice javascript lato client (jsts)? In effetti potrei vivere perdendo alcuni dettagli finché le aree mostrate nel mio risultato rimangono separate e il calcolo diventa (molto) più veloce.

Mettendo da parte la serializzazione GeoJSON, il mio laptop impiega circa 6,3 secondi:

SELECT
  ST_MakePolygon(
    ST_ExteriorRing(
      (ST_Dump(
        ST_Union(
          ST_Buffer(geom, 20, 2)))).geom))
FROM bz_edges

Guardando i dati in OpenJUMP, ho notato un bel po 'di dettagli nei segmenti di strada, rispetto al livello di dettaglio desiderato nell'output. Sembra che anche una semplificazione al volo di queste linee possa produrre un grande aumento di velocità in PostGIS:

SELECT
  ST_MakePolygon(
    ST_ExteriorRing(
      (ST_Dump(
        ST_Union(
          ST_Buffer(ST_Simplify(geom, 10), 20, 2)))).geom))
FROM bz_edges

che porta le cose a 2,3 secondi. Ho pensato che avrei potuto fare meglio memorizzando la geometria generalizzata in una colonna separata, invece di calcolarla al volo, ma in realtà non ha fornito alcun vantaggio aggiuntivo.

A seconda della quantità di codice che sei disposto a scrivere, puoi quasi sicuramente fare di meglio in Java, se non altro perché puoi sfruttare più core. (Per quello che vale, JTS esegue l'operazione sopra in 2,8 secondi). Un approccio potrebbe essere quello di estendere CascadedPolygonUnionper far sì che alcune delle operazioni sindacali avvengano in parallelo. (aggiornamento - ecco un ParallelCascadedPolygonUnion )

Ho notato nei dati di esempio che i bordi sono memorizzati con riferimenti ai loro nodi iniziale e finale, ovvero che hai un grafico predefinito. Ho il sospetto che puoi generare questi poligoni molto più rapidamente se lavori dal grafico invece di utilizzare operazioni geometriche generiche. Ad esempio, penso che potresti così qualcosa del genere:

1. identificare i componenti collegati del grafico
2. per ogni componente collegato, trova il nodo con la coordinata X minima (garantito che si trovi all'esterno del componente)
3. percorrere i bordi del componente, girando sempre a sinistra (o destra) quando possibile. Questo ti darà l'anello esterno di ciascun componente.
4. poligonizzare l'anello esterno e il buffer in modo appropriato.