Comments and Ratings

works great! thanks

For my version(7.8.0),it changes the figure axes size.

SYNTAX: <gridaxeshandle>=cgrid(<colorarg, stylearg, colorargy>)
gridaxishandle=cgrid('g-');

Just a quick note...Mac OSX 10.5 Matlab Release 2008a
 Compiled and ran example first time using exactly
the instructions from ReadMe.txt
(cut and pasted them to matlab command window)
Compiler used gcc version 4.0.1 (Apple Inc. build 5465)
(default on my system)
Thanks for terse and sufficient instructions.

Sebastian, I just downloaded your function file and still have the problem that Joanne is mentioning. I have MatlabR2008a.

Very good.

In reply to Joanne Hung:
I had fixed this bug a while ago, but forgot to update it here on the FEX. It was caused by a call to Matlabs "version"-command, which has somewhat changed its bevavior ... file is updated and should work as expected!

Yes, Obviously it is very fast to find intersection point between curves

Hi Sebastian,
Just wanted to let you know I also created a similar function:

http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=15850&objectType=file

Usefull. Congratulations. It help-me to understand how to extract .hgt files from SRTM.
Thanks.

Could we use it for a higher dimension?

very useful

Works well for me

yes yes

This polygon clipper works very well and easy to use, also has good quality!!

Took a lot of work to run on my linux machine. The problem is that the
gpc_mexfile sources use '//' to begin the comments, and this is not part
of the C standard. This probably means the programs were written on a
Windows machine, which uses Microsoft Visual C++ to compile C code.
'//' is the comment prefix in standard C++. Microsoft appears to
believe that C++ is a perfect superset of C, which isn't true.

I removed all the lines beginning with // from those two source files
and the mex command in the readme gave worked fine.

Also, it won't run unless I had the older gcc-3.3 package installed.

Also, the zip file ships with Example.m which doesn't work. PolyClipper_example.m does work. Looks like a great function, though, if these things get tidied up.

You may use something like that

if x<0; LON = 'W' ;
else; LON = 'E' ;
end
if y<0; LAT = 'S' ;
else; LAT = 'N' ;
end
filename=[path LAT num2str(abs(y),'%02i') LON num2str(abs(x),'%03i') '.hgt']

Worked first time. Very easy to use. Did exactly what I needed. (And not an easy thing to program for yourself, as I found out the hard way!)

great command, thank you!
Are you planning to include the case of infinite line intersection?
Example:
x1=[0 1]; y1=[0 0];x2=[0.5 0.5]; y2=[0.1 1];
will "intersect" at [0.5,0]

nice idea
there are some issues that need to be addressed:
- the help section does NOT work at all (wrong indentation of the %-markers)
- once GRIDCOLOR was run for an axis, a subsequent call to PLOT will spit out numerous annoying warnings...
us

Just what I needed. I have been racking my brains for days to get to a point where my program starts to work, but this one is much better and faster!. Thanks a lot.

Doesn't work for me if either lat or lon is an integer, e.g.
>> out=GetSRTMData([13.0,51.21]);
Patch like this:
lon(1) = floor(min(tmp(:,1)));
lon(2) = ceil(0.5+max(tmp(:,1)));
lat(1) = floor(min(tmp(:,2)));
lat(2) = ceil(0.5+max(tmp(:,2)));

However, nice tool!