Hi Roberto,
This sometimes this happens as when tiling a pulse is associated with a tile
based on the pulse index value (i.e., normally first or last return). However,
if some of the returns associated with the pulse are well outside the tile the
bounding box of the tile will extended due to these points.
In the case you are showing, have you indexed the pulses using the last return?
And is there a pulse with a noise return several hundred metres in the air at
the edge of a swath which is causing what I described above?
Or there could be a pulse which has been incorrectly built from the LAS file
(i.e., the wrong returns have been corrected - I have had cases of this when
the input LAS file is not provided in strict return by pulse order). If you
load all the data within the tile try turning on the pulse vectors have see if
there is a blue line going off at an ‘odd’ (incorrect) angle.
Hope that helps and makes sense.
Cheers, Pete
****************************************************
* Dr Pete Bunting
* Senior Lecturer in Remote Sensing
* Earth Observation and Ecosystem Dynamics Group
* Department of Geography and Earth Sciences
* Aberystwyth University
* Aberystwyth
* Ceredigion
* SY23 3DB
* UK
*
* Ph: +44 (0) 1970 622615
* Mob: +44 (0) 7917 842743
* NZ Ph: +64 (0) 4 280 7430
* Email: [email protected]
****************************************************
On 25 Nov 2013, at 20:49, Roberto Antolín <[email protected]> wrote:
> I am working with a very wide LiDAR dataseti. I am using spd to tile
> it and to process it:
> * 'spddeftile --extent' to know the extension of my dataset, and
> * 'spddeftile --tiles' to define the tiles (500mx500m).
>
> I have checked the output xml defining the tiles and both the tile
> cores and tile extensions (overlap of 10m) are correct. However, some
> of the tiles 'spdtiling' creates are much wider (some hundred meters)
> than they should be, even considering the overlaping buffer. For
> example, tile row4col30 its definition in the xml file is:
>
> <tile col="30" corexmax="254000" corexmin="253500" coreymax="697000"
> coreymin="696500" file="" row="4" xmax="254010" xmin="253490"
> ymax="697010" ymin="696490"/>
>
> but its bounding box is:
>
> BBOX [xmin, ymin, xmax, ymax]: [253485.53,696489.959998,254013,697251.219998]
>
> I attached a screenshot of the tile imported in SPDPointViewer.
>
> I tried 'spdtiling' with both '--all' and '--extract' options and it
> behaves the same way.
> I checked and it actually leaves a point outside the correct bbox. The
> coordinates of that points are (253500, 697251.219998). What it is
> suspicious to me is the fact that the X coordinate is exactly the same
> value of the corexmin.
>
> I do not know whether this is a bug or it is something related to data.
>
> Cheers,
> Roberto.
>
> --
> Roberto
> <500m_row4col30.png>------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________
> spdlib-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/spdlib-develop
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
spdlib-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spdlib-develop
