Points2Grid and high resolution high density small grids about points2grid HOT 8 CLOSED

Hi Ken,

I did see the email go by last week but I was traveling. I would say the sourceforge list is probably still the correct place for project-level interaction, but this github repository is probably the center of mass for development activities for now. I think the original developer is going to have to be the one to reply to your query. Other than a cursory test or two, I haven't actually used p2g, and Will, the developer who did the bulk of the changes to support CMake, boost, etc did so with a "do no harm" mentality that didn't really dig in and attempt to touch any of the algorithmic content of the software. In short, other than expecting a DEM-like output from running it, we know as much about how it works as you do :)

Howard

from points2grid.

OK. Thanks for the heads up. I'll look into this as I use it more and if I figure out what is going on update this tickted and/or push a changeset.

from points2grid.

Hi @mankoff !

Will here. As @hobu said, I didn't really dig into the algorithms that points2grid used. I'm tied down in an internal project right now, but will try to look into this as time allows. We need correct results from our software at least as much as you do :-).

Having access to a file that's triggering this behavior would markedly improve my chances of fixing it. When you get a chance, could you please send me either the file you've mentioned, or a scrubbed one that reproduces the behavior described?

-- Will

from points2grid.

sample data input: http://dl.dropbox.com/u/12453163/test.pgm.xyz
output: http://dl.dropbox.com/u/12453163/test.pgm.xyz.den.grid

from points2grid.

Thanks a bunch, Ken! I'll try to take a look at it if I get some time free during business hours today. (It's after midnight local time here in Virginia now.)

from points2grid.

It's looking like this may be stemming from unit conversion/interpretation. points2grid uses an internal unit of feet. And the command line that you gave will be interpreted as requesting a resolution of 0.0032808401 feet = 0.00100000006 meters.

And a quick check suggests that the grid sizes are exactly what you'd asked for, given the parameters you supplied on the command line:

new-host:Debug wmangley3$ python
Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0.533365 -- 0.454966
0.988331
>>> _ / 303
0.0032618184818481847
>>> 0.411059 -- 0.357392
0.768451
>>> _ / 236
0.0032561483050847456
>>> 303 * 236
71508
>>> 296104 / 71508
4
>>> 

That said, the values in your file are going to be interpreted as though they are decimal feet, not decimal meters! This can't possibly be what you want. You should probably convert the file's units to feet and try again. The units program is your friend here.

from points2grid.

OK all that makes sense to me so far. I got confused with the unit conversion. A bit odd that this operates in imperial units... Point density of 50 is still confusing. Should I interpret this to be 50 points per square foot? I assumed it would be points per resolution, or in this case points per 0.003 foot, or points per mm, but clearly that is not the case.

from points2grid.

Not a conversion issue since p2g doesn't actually know about units.

from points2grid.