Problema inserimento file ESRI ASC

Ciao a tutti, tempo fa ho riscontrato delle anomalie nell’inserimento dei file ESRI ASC come nuvole di punti in Civil 3D. Ho segnalato il problema al ns. rivenditore ma non ho mai avuto risposta quindi chiedo a voi se qualcuno ha riscontrato lo stesso problema e se volesse verificare la cosa. Veniamo al dunque.
Il problema si presenta nell'inserimento di una nuvola di punti in formato ESRI ASC la cui struttura la puoi vedere nei seguenti link:

http://en.wikipedia.org/wiki/Esri_grid
http://resources.esri.com/help/9.3/a...ter_format.htm

In particolare, esaminando un file di esempio, le prime righe portano le seguenti informazioni:

NCOLS 1363
NROWS 1325
CELLSIZE 1.000
XLLCENTER 718000.500
YLLCENTER 5160000.500
NODATA_VALUE -9999.000

Il che, vorrebbe dire che il punto posto al centro della cella nell'angolo inferiore sinistro dovrebbe avere coordinate 718000.500,5160000.500. Importando il file con Civil 3D il punto in questione si trova sulle coordinate 718000.000,5160000.000 quindi con una traslazione pari a -0.500;-0.500 (pari a ovviamente metà del lato della griglia). Se cambio il valore di XLLCENTER con XLLCORNER e YLLCENTER con YLLCORNER l’errore persiste, in tal caso il punto in questione dovrebbe trovarsi sulle coordinate 718001.000,5160001,000 invece importandolo con C3D si trova sulla posizione 718000.500,5160000.500. Anche in questo caso si ha una traslazione del valore –CELLSIZE/2 sia in X che in Y
Nel caso in esame, su pendii abbastanza ripidi, diciamo nell'ordine dei 30°-40° un errore del genere porta ad un errore di quota che si aggira fra i 28 e i 42 cm (considerando la traslazione in una sola direzione). Tale errore, in applicazioni in cui si richiede una certa precisione è largamente oltre i limiti di tolleranza.
N.B. ho provato l’inserimento dei file ESRI ASC con Global Mapper, in questo caso le nuvole di punti vengono inserite nella corretta posizione. E’ già la seconda volta che con un programma dal costo di 1/20 di CIVIL3D riesco a risolvere delle lacune presenti nel software Autodesk!!!!

Attendo fiducioso dei riscontri!!

Ciao,

ho fatto alcune prove con i file che avevo a disposizione e ho riscontrato che le impostazioni, sia con XLLCORNER e XLLCENTER (e analoghi per le Y) funzionano, ma, a seconda delle impostazioni internazionali presenti sul sistema, vengono troncati i decimali (cioè quel mezzo metro che è presente sul tuo header del file .asc.

In poche parole, riepilogando ciò che ho riscontrato, sul mio sistema (separatore decimale con il punto), inserendo il file di esempio che avevo a disposizione (in cui le due coordinate avevano il separatore con la virgola), veniva creata la superficie (o la nuvola di punti) troncando al valore intero senza aver alcun messaggio di errore.

Penso che tu abbia le impostazioni italiane sul tuo sistema (cioè separatore decimali con la virgola) e il tuo file fosse invece con il punto, cioè la situazione opposta alla mia.

Sto usando Civil 3D 2013, per la cronaca, e tutto ha funzionato alla perfezione (i bordi del modello sono quelli attesi).

fai una prova e dicci se ha funzionato bene anche per i tuoi dati

ciao

Guido

PS: Ringrazio Stefano per il supporto (e la pazienza)

Ciao Guido, grazie dell'interessamento, il discorso del separatore decimale lo avevo già notato, infatti lo ho riportato anche nella discussione sul blog di GimmiGis su Facebook.

Il problema, anzi il mio pensiero, è che se il file ASC viene trattato come una nuvola di punti, il punto deve essere considerato al centro dell'ipotetica cella a cui lo stesso punto appartiene. Invece Civil3D (anch'io uso il 2013) pone il punto nell'angolo in basso a sx della cella.

Ho provato a inserire lo setsso file ASC in tre modi:
- come raster mediante connessione FDO
- come nuvola di punti (CREATEPOINTCLOUD)
- importare la superficie da DEM (CreateSurfaceGridFromDEM)

Se inserito come raster, l'inserimento viene fatto correttamente, mentre negli altri due casi la maglia regolare di punti (sia la nuvola nel secondo caso, che la superfice nel terzo) vengono inserite nell'angolo in basso a sx del raster.
Io invece mi aspetterei che i dati vettoriali (nuvola e/o superficie) venissero inseriti centrati sul Raster, ossi con un dx e dy pari a metà della dimensione delle celle.

Ora, il mio intento, sarebbe sapere se il mio concetto è sbagliato, e l'inserimento corretto è quello del software, o se invece vi è un errore su CIVIL3D.

Tutto questo ragionamento è uscito su un caso reale, io e i miei colleghi non riuscivamo a capire perchè ci trovavamo degli errori di quota non ammissibili nel confronto fra una superficie generata con CIVIL e poi ricontrollata su campo, gli errori erano maggiori laddove si avevano maggiori pendenze.
Quando ci siamo accorti di questa, a nostro parere, incongruenza nell'inserimento, dopo aver studiato la struttura del file ESRI ASC, abbiamo traslato tutta la superficie di dx e dy con valore pari a metà cella e tutto è andato a posto.

Un'altra prova che abbiamo eseguito è stata trasformare il fil ASC precedentemente usato, in formato LAS con un altro software (Global Mapper per essere precisi), e poi importarlo in CIVIL3D come nuvola di punti, guarda caso la nuvola in questo caso veniva inserita in modo corretto, ossia centrata sul file DEM importato come raster (il tutto su C3D).

Spero di aver espresso in modo chiaro il tutto

Ho provato a fare un ulteriore prova che di seguito riporto.
Ho utilizzato una file ASC il cui header è il seguente:

ncols 485
nrows 390
xllcorner 696857.375
yllcorner 4507835.101
cellsize 1
NODATA_value -9999

1 - Inserimento del file ASC di prova come Raster con connessione FDO

Allegato 240

2 - Estrazione delle curve di livello dal raster (seleziono il raster dal riquadro attività -> tasto dx -> Crea layer curve di livello)

Allegato 241

3 - Insermento della superficie da DEM (_CreateSurfaceGridFromDEM)

Allegato 242

4 - Visualizzazione della superficie con curve di livello

Allegato 243

Ora se effettuo uno ZOOM su una porzione di superficie vedo che le curve di livello create in due modi differenti dalla stesso file presentano difformità di posizione abbastanza marcate:

Allegato 244

Se ora traslo la superficie inserita al punto 3 di un valore pari a 0,5m sia in X che in Y (valore pari a metà della dimensione della cella) mi trovo questo:

Allegato 245

Secondo il mio parere la superficie traslata combacia molto meglio con il DEM caricato inizialmente.

Ci siamo sentiti fuori dal forum con Hermann, che sta facendo delle verifiche e, allo stesso tempo, sta chiedendo un chiarimento ad Autodesk.
Anche io ho fatto qualche piccola richiesta a voce e quello che ho (finora) appurato è che molto dipende da come vengono registrati i dati.
Mi spiego meglio con due esempi.

Se la mia maglia rappresenta dei campionamenti fatti cpn un certo passo in punti ben precisi (per esempio con rilievo laser), allora è opportuno, per la precisione, che parta (per esempio con XLLCORNER e YLLCORNER) in modo da individuare le coordinate (X,Y) dei punti effettivamente campionati.

Se, inceve, la mia maglia rappresenta una "media" fatta per semplificare tanti valori che ho sulla cella, allora la precisione del punto (x,y) è meno stringente, ma vedo bene rappresentarla con un punto al centro della cella (XLLCENTER e YLLCENTER).

Nella descrizione che vedo in quella pagina sul sito ESRI non trovo molto dettaglio su questi criteri, che mi paiono molto di buon senso.
Sono di buon senso, ma, per loro natura, spesso queste superfici DEM non vengono utilizzate come le superfici TIN, e questo potrebbe essere un motivo che chiarisce il problema.

La superficie TIN, che specifica anche la x,y dei punti ritenuti interessanti per descrivere meglio una superficie (quindi sono irregolari, non disposte su una maglia equispaziata), viene in genere "curata meglio" anche per le x e per le y.

La superficie DEM, invece, non è che sia "imprecisa", ma di norma serve per dare una rappresentazione più generale di una area generalmente più ampia di ciò che si fa con la TIN, quindi si utilizza per scopi diversi e anche le attese possono essere diverse.

Detto tutto ciò, nulla nega che si possano utilizzare bene le superfici DEM (specialmente se il passo è piccolo e se le superfici sono regolari) e che si abbia la giusta attesa di trovare dati precisi in posizioni precise (almeno per quelle dove ho la certezza che sia stata fatta una lettura strumentale).


Non so se questo aiuta a capire o a risolvere il problema, ma era solo per far capire che lo standard possa essere, in qualche caso, usato in modo impreciso (soprattutto se non è chiaro cosa è stato registrato).

ciao

Guido

Ho avuto dei confronti con Karsten Saenger del team di supporto Autodesk, dopo qualche mail gli ho trasmesso un sunto di tutte le prove fatte e in prima battuta mi ha risposto questo:

Citazione:

---

thank you for providing all the information, screenshots and test data.
I spent some time today in the try to understand the problem and came to the conclusion that you are saying that there is a difference when importing the same ESRI ASC file into Civil 3D - depending on the method. The difference is half a pixel.
Is this correct?

To check Civil 3D I did a test on my side and loaded the two test files for "corner" and "center" into Civil 3D.
I used the FDO connection, the point cloud and the import DEM functions.

After the import all data from the center file lined up and all data from the corner file lined up too.
Please see this screenvideo:
http://screencast.com/t/gGxOzlEs

Basically what happens is that you have a start coordinate pair (x,y) and then you tell the progam if this coordinate should be the center of a cell with size 1 in your case or if the coordinate should represent the lower left corner.

In conclusion from my point of view Civil 3D behaves as expected and it is exactly doing what you tell it to do.

Please let me know if this answers your question or if I did not understand you correctly.

---

Poco dopo però è seguita un'altra mail:

Citazione:

---

I think I have understood the issue, I just read through another case with the same issue and it became clearer:
The x,y coordinates are correct depending on "corner" or "center" setting.
The Z value seems to be the problem - when using center it is ok, because the Z is in the center of each cell and the interpolation from cell to cell is correct.
When using "corner" the Z value sits on the corner of the cell. If you interpolate to the next cell with a line the Z value is not correct for the cell.
That explains why everything is correct when using a pixel based DEM, becaus the whole pixel has the same Z value.

I will continue investigating in this case and come back to you.

---

Secondo me non abbiamo ancora centrato il problema, come lo intendo io, ma ci stiamo comunque avvicinando. Almeno credo.

Capisco.
Io credo che, come abbiamo detto qualche giorno fa, tutto dipenda da come sono definiti sul sito ESRI (e c'è poco da dire, i punti "fiduciali", o meglio rilevati, sono allineati a partire dal bordo (CORNER) o dal centro (CENTER), sta poi a chi scrive il file di mettere i dati coerentemente.

Secondo me il succo è questo, non per rimandare il problema, ma perchè potrebbe essere che ci sia qualche problema lì.

Di fatto poi la verifica è semplice, anche se (sono d'accordo con te) quando qualcuno mi passa dei dati li vorrei usare direttamente e basta.
Se, invece, il formato dei dati è coerente e facesse qualche errore il (nostro) Civil, allora cerchiamo di farlo capire ad Autodesk..


ciao

Guido