<div dir="ltr">Hello Howard,<div>Yes, after reviewing my Github setup, apparently it wasn't fetching properly. Now everything works as advertised. Sorry for the bother.</div><div><br></div><div>Roger</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 6:42 PM, Roger Bedell <span dir="ltr"><<a href="mailto:sylvanascent@gmail.com" target="_blank">sylvanascent@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Howard,<div>I thought I fetched the latest from master yesterday and recompiled, but perhaps I don't know what I'm doing with Github, I will look more closely. That patch seems to be exactly what I'm looking for.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Roger</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 6:22 PM, Howard Butler <span dir="ltr"><<a href="mailto:hobu.inc@gmail.com" target="_blank">hobu.inc@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Roger,<br>
<br>
I think Paul submitted a patch to do this in <a href="https://github.com/PDAL/PDAL/issues/143" target="_blank">https://github.com/PDAL/PDAL/issues/143</a><br>
<br>
Because of the way we use the Inplacereprojection filter from oracle, we load cloud objects per-file (with each having its own scale/offset), so we haven't run into this before.<br>
<span><font color="#888888"><br>
Howard<br>
</font></span><div><div><br>
<br>
On Jul 15, 2013, at 11:12 AM, Roger Bedell <<a href="mailto:sylvanascent@gmail.com" target="_blank">sylvanascent@gmail.com</a>> wrote:<br>
<br>
> Hello Howard,<br>
> Thanks for your quick reply. I would like to make a suggestion.<br>
><br>
> - if the offset is specified in the options, use it exactly as specified.<br>
> -if not specified, derive a suitable offset from the data.<br>
><br>
> The reason is that with pgPointCloud, it is possible to add many LAS files to the same table. Only the user knows what might be a suitable offset beforehand.<br>
><br>
> I can try my hand at this if you dont have the time, if you can point me in the right direction.<br>
><br>
> Regards,<br>
> Roger<br>
><br>
> Sent from my iPad<br>
><br>
> On Jul 15, 2013, at 16:00, Howard Butler <<a href="mailto:hobu.inc@gmail.com" target="_blank">hobu.inc@gmail.com</a>> wrote:<br>
><br>
>><br>
>> On Jul 14, 2013, at 12:08 PM, Roger Bedell <<a href="mailto:rbedell@coordinatesolutions.com" target="_blank">rbedell@coordinatesolutions.com</a>> wrote:<br>
>>> Note, the Latitude is -21.4745 instead of around 36.09.<br>
>><br>
>> The combination of scale * raw in32_t + offset values are overflowing past 32 bits. You probably need to dial the scale back to 0.0000001 or 0.000001.<br>
>><br>
>><br>
>>> <pc:scale>0.00000001000000</pc:scale><br>
>>> <pc:offset>0.000297639019</pc:offset><br>
>>> Why is pc:offset = 0.0002976, when I explicitly asked for an offset of 33 in the pipeline XML?:<br>
>><br>
>> It's trying to calculate an offset for you based on the offset of the incoming data. Try turning up the debug noise with -d and -v 7 to see it spits out any illuminating noise.<br>
>><br>
>>><br>
>>> <?xml version="1.0" encoding="utf-8"?><br>
>>> <Pipeline version="1.0"><br>
>>> <Writer type="drivers.pgpointcloud.writer"><br>
>>> <Option name="connection">host='localhost' dbname='LIDAR2' user='postgres'</Option><br>
>>> <Option name="table">qtest4326</Option><br>
>>> <Option name="srid">4326</Option><br>
>>> <Option name="overwrite">true</Option><br>
>>> <Filter type="filters.chipper"><br>
>>> <Option name="capacity">400</Option><br>
>>> <Filter type="filters.cache"><br>
>>> <Option name="max_cache_blocks">3</Option><br>
>>> <Option name="cache_block_size">32184</Option><br>
>>> <Filter type="filters.inplacereprojection"><br>
>>> <Option name="in_srs">EPSG:26914</Option><br>
>>> <Option name="out_srs">EPSG:4326</Option><br>
>>> <Option name="offset_x">-104</Option><br>
>>> <Option name="offset_y">33</Option><br>
>>> <Option name="offset_z">0.0</Option><br>
>>> <Option name="scale_x">0.00000001</Option><br>
>>> <Option name="scale_y">0.00000001</Option><br>
>>> <Option name="scale_z">0.001</Option><br>
>>> <Reader type="drivers.las.reader"><br>
>>> <Option name="filename">NRCSTEST10k.las</Option><br>
>>> <Option name="spatialreference">EPSG:26914</Option><br>
>>> </Reader><br>
>>> </Filter><br>
>>> </Filter><br>
>>> </Filter><br>
>>> </Writer><br>
>>> </Pipeline><br>
>>><br>
>>> When I increase the scale_x and scale_y to 0.0000001, it works better. To me this seems like the offset isn't being written correctly, and with the smaller scale, the 32 bit int overflows due to the incorrect offset_y value.<br>
>><br>
>> InplaceReprojection filter tries to be smart and allow you to merely set the scale value and back-calculate an offset based on the offset of the X dimension that's coming from the LAS reader. If that calculation overflows, bad things happen. I used to trap for overflows, but the cost of that trap happening per-dimension-per-point was prohibitive. Maybe I should try to put it back in debug mode or something.<br>
>><br>
>>> I was able to reproduce this using your UTM17.LAS sample data. Using this pipeline XML:<br>
>>><br>
>>><br>
>>> <Pipeline version="1.0"><br>
>>> <Writer type="drivers.las.writer"><br>
>>> <Option name="filename">UTM17_out.las</Option><br>
>>> <Option name="spatialreference">EPSG:4326</Option><br>
>>> <Filter type="filters.inplacereprojection"><br>
>>> <Option name="in_srs">EPSG:32617</Option><br>
>>> <Option name="out_srs">EPSG:4326</Option><br>
>>> <Option name="offset_x">-84.0</Option><br>
>>> <Option name="offset_y">38.0</Option><br>
>>> <Option name="offset_z">0.0</Option><br>
>>> <Option name="scale_x">0.0000001</Option><br>
>>> <Option name="scale_y">0.0000001</Option><br>
>>> <Option name="scale_z">0.01</Option><br>
>>> <Reader type="drivers.las.reader"><br>
>>> <Option name="filename">UTM17.las</Option><br>
>>> <Option name="spatialreference">EPSG:32617</Option><br>
>>> </Reader><br>
>>> </Filter><br>
>>> </Writer><br>
>>> </Pipeline><br>
>><br>
>> With current PDAL/PDAL:master, this seems to produce what is expected for me. Any chance you can try with the latest code? If you're still stuck, please catch me on IRC.<br>
>><br>
>> Thanks for being willing to dive into PDAL. It is still very much software that is growing, and there's still a number of pointy bits like this throughout.<br>
>><br>
>> Howard<br>
>><br>
>><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div><br clear="all"><div><br></div>-- <br>Roger Bedell<br>Coordinate Solutions Inc.<br>